Re: [Python-Dev] Microsoft Visual C++ Compiler for Python 2.7

[Ryan Gonzalez]

At long last! Building C extensions on Windows will no longer be a pain in
the rear!

On Fri, Sep 26, 2014 at 1:01 PM, Steve Dower 
wrote:

> Hi all,
>
> (This is advance notice since people on this list will be interested.
> Official announcements are coming when setuptools makes their next release.)
>
> Microsoft has released a compiler package targeting Python 2.7 (i.e. VC9).
> We've produced this package to help library developers build wheels for
> Windows, but also to help users unblock themselves when they need to build
> C extensions themselves.
>
> The Microsoft Visual C++ Compiler for Python 2.7 is available from:
> http://aka.ms/vcpython27
>
> This package contains all the tools and headers required to build C
> extension modules for Python 2.7 32-bit and 64-bit (note that some
> extension modules require 3rd party dependencies such as OpenSSL or libxml2
> that are not included). Other versions of Python built with Visual C++ 2008
> are also supported.
>
> You can install the package without requiring administrative privileges
> and, with the latest version of setuptools (when it releases), use tools
> such as pip, wheel, or a setup.py file to produce binaries on Windows.
>
> Unfortunately, this package isn't necessarily going to help with building
> CPython 2.7 itself, as the build process is complicated and Visual Studio
> 2008 is practically required. However, as most people aren't building
> CPython on Windows, this isn't a huge issue. This compiler package should
> be sufficient for most extension modules.
>
> I should also point out that VC9 is no longer supported by Microsoft. This
> means there won't be any improvements or bug fixes coming, and there's no
> official support offered. Feel free to contact me directly <
> steve.do...@microsoft.com> if there are issues with the package.
>
> Cheers,
> Steve
>
> ___
> 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/rymg19%40gmail.com
>



-- 
Ryan
If anybody ever asks me why I prefer C++ to C, my answer will be simple:
"It's becauseslejfp23(@#Q*(E*EIdc-SEGFAULT. Wait, I don't think that was
nul-terminated."
Personal reality distortion fields are immune to contradictory evidence. -
srean
Check out my website: http://kirbyfan64.github.io/
___
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] [OFF-TOPIC] It is true that is impossible write in binary code, the lowest level of programming that you can write is in hex code?

[Ryan Gonzalez]

Wait...you sent this to 9fans AND Python Dev??? Why not ask on StackExchange
Programmers  or something?

On Mon, Nov 3, 2014 at 5:19 PM, françai s  wrote:

> I intend to write in lowest level of computer programming as a hobby.
>
> It is true that is impossible write in binary code, the lowest level of
> programming that you can write is in hex code?
>
> What is the lowest level of programming computers that you can write ?
>
> Is binary code?
>
> Is hex code?
>
> Is another machine code? Honestly do not know if it is true that there is
> another machine code beyond the binary and hex code.
>
> Is Assembly?
>
> ___
> 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/rymg19%40gmail.com
>
>


-- 
Ryan
If anybody ever asks me why I prefer C++ to C, my answer will be simple:
"It's becauseslejfp23(@#Q*(E*EIdc-SEGFAULT. Wait, I don't think that was
nul-terminated."
Personal reality distortion fields are immune to contradictory evidence. -
srean
Check out my website: http://kirbyfan64.github.io/
___
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] Improvements for Pathlib

[Ryan Gonzalez]

+1 for the context manager ideas. Anything that is like a resource should
be available as a context manager.

On Sat, Nov 8, 2014 at 9:46 AM, Ionel Cristian Mărieș 
wrote:

> Hello,
>
> In the current incarnation Pathlib is missing some key features I need in
> my usecases. I want to contribute them but i'd like a bit of feedback on
> the new api before jumping to implementation.
>
> The four things I need are:
>
> #1. A context manager for temporary files and dirs (that cleans everything
> up on exit). Eg:
>
> with pathlib.TmpDir(suffix='', prefix='') as tmp:
>   assert isinstance(tmp, pathlib.Path)
>
> with pathlib.TmpFile(suffix='', prefix='') as tmp:
>   assert isinstance(tmp, pathlib.Path)
>
> #2. A context manager for changing working directory (that switches to the
> old cwd on exit). Eg:
>
> with path.cd():
>  assert os.getcwd() == path
>
> #
> ​3​
> . Shutil-like features:
>
> - copy_file
> - copy_dir (or copy_tree?)
> - copy (does copy_dir or copy_file depending on what the source is. How to
> handle symlinks?)
> - rm_dir (or rm_tree? Also, this would be required for the TmpDir path).
>
> #4. Zip files support. A specialised Path subclass that works inside a zip
> file. I'm ok having this as an external package but some discussion would
> be useful as I'd have to rely on pathlib internals.
>
> After some brief looking in the pathlib code it would appear the wise
> thing would be to have the zip path as the "drive" for the ZipPaths that
> refer to files inside the zip.
>
> I'm not sure where the best place is to store the internal zipfile object.
> Perhaps the accessor?
>
> Ideally the ZipFiles would work with the shtuil-like api just fine (or at
> least the readonly operations).
>
> Thanks,
> -- Ionel M.
>
> ___
> 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/rymg19%40gmail.com
>
>


-- 
Ryan
If anybody ever asks me why I prefer C++ to C, my answer will be simple:
"It's becauseslejfp23(@#Q*(E*EIdc-SEGFAULT. Wait, I don't think that was
nul-terminated."
Personal reality distortion fields are immune to contradictory evidence. -
srean
Check out my website: http://kirbyfan64.github.io/
___
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] Windows Dedicated Mailing List

[Ryan Gonzalez]

I agree completely (although I use multibooting instead of a VM).

On Fri, Nov 14, 2014 at 11:46 AM, Antoine Pitrou 
wrote:

> On Fri, 14 Nov 2014 16:35:12 +
> Steve Dower  wrote:
> > I'd like to keep development *of* Python here, regardless of platform.
> Otherwise all the Linux and Mac people might forget about us :)
>
> +1 from a Linux developer. I find it useful to know what happens on
> other platforms (also I occasionally fire a Windows VM to do some
> development).
>
> Regards
>
> Antoine.
>
>
> ___
> 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/rymg19%40gmail.com
>



-- 
Ryan
If anybody ever asks me why I prefer C++ to C, my answer will be simple:
"It's becauseslejfp23(@#Q*(E*EIdc-SEGFAULT. Wait, I don't think that was
nul-terminated."
Personal reality distortion fields are immune to contradictory evidence. -
srean
Check out my website: http://kirbyfan64.github.io/
___
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?

[Ryan Gonzalez]

On Sun, Nov 23, 2014 at 1:41 PM, Ethan Furman  wrote:

> On 11/23/2014 10:14 AM, Brett Cannon wrote:
> > On Sun Nov 23 2014 at 1:08:58 PM Ethan Furman 
> wrote:
> >>
> >> Dous GitHub support hg?  If not, I am strongly opposed.
> >>
> >
> > Depends on what you mean by "support". If you mean natively, then no. If
> > you mean "I want more of a hg CLI" then you can get that with
> > http://hg-git.github.io/ .
>
> Well, if somebody documents it, I suppose I can follow along.  ;).


I haven't used it in a while, but it was something like this (after it's
installed):

- Put the git repo url in .hgrc:

[paths]
default=git+https://github.com/my_user/my_repo.git

[auth]
github.prefix = git+https://github.com/my_user/my_repo.git
github.username = my_user
github.password = my_password

Unless you put the login info there, it won't work (for some reason).

Then, whenever you're going to push, first do:

hg bookmark -r default master

I'd love to test this right now, but I'm on Chrome OS...



>
> > And can I just say this is all bringing back "wonderful" flashbacks of
> the
> > SourceForge to our own infrastructure move as well as the svn to hg
> move. =/
>
> My apologies.  Change can be hard.
>
> My concern is that we will end up with multiple different workflows
> depending on which part of Python we're working on,
> which will lead to more time spent learning more about how to do it
> instead of doing it, and more time spent recovering
> from errors because of the differences.
>
> --
> ~Ethan~
>
>
> ___
> 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/rymg19%40gmail.com
>
>


-- 
Ryan
If anybody ever asks me why I prefer C++ to C, my answer will be simple:
"It's becauseslejfp23(@#Q*(E*EIdc-SEGFAULT. Wait, I don't think that was
nul-terminated."
Personal reality distortion fields are immune to contradictory evidence. -
srean
Check out my website: http://kirbyfan64.github.io/
___
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] Google search labels Python 2.7 docs as Python 3.4

[Ryan Gonzalez]

Not sure if this is something to post here...but...

[image: Inline image 1]

-- 
Ryan
If anybody ever asks me why I prefer C++ to C, my answer will be simple:
"It's becauseslejfp23(@#Q*(E*EIdc-SEGFAULT. Wait, I don't think that was
nul-terminated."
Personal reality distortion fields are immune to contradictory evidence. -
srean
Check out my website: http://kirbyfan64.github.io/
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] python 2.7.9 regression in argparse?

[Ryan Gonzalez]

I thought of this exact comment when I read the "bug fix considered a
regression."

On Tue, Jan 6, 2015 at 2:41 PM, Guido van Rossum  wrote:

> There's an obligatory XKCD reference for this: http://xkcd.com/1172/
>
> On Tue, Jan 6, 2015 at 12:25 PM, Terry Reedy  wrote:
>
>> On 1/6/2015 7:39 AM, Victor Stinner wrote:
>>
>>> More context:
>>>
>>> 2014-12-19 12:43 GMT+01:00 anatoly techtonik :
>>>
 https://github.com/nickstenning/honcho/pull/121

>>>
>>> The link mentions the following changeset:
>>> ---
>>> changeset:   93122:1a3143752db2
>>> branch:  2.7
>>> parent:  93112:927cca0b9337
>>> user:R David Murray 
>>> date:Fri Oct 17 20:07:08 2014 -0400
>>> files:   Lib/argparse.py Lib/test/test_argparse.py Misc/NEWS
>>> description:
>>> #9351: set_defaults on subparser is no longer ignored if set on parent.
>>>
>>> Before, if a default was set on the parent parser, any default for that
>>> variable set via set_defaults on a subparser would be ignored.  Now
>>> the subparser set_defaults is honored.
>>>
>>> Patch by Jyrki Pullianinen.
>>>
>>>
>>> diff -r 927cca0b9337 -r 1a3143752db2 Lib/argparse.py
>>> --- a/Lib/argparse.py   Fri Oct 17 16:20:15 2014 -0500
>>> +++ b/Lib/argparse.py   Fri Oct 17 20:07:08 2014 -0400
>>> @@ -1089,7 +1089,14 @@ class _SubParsersAction(Action):
>>>   # parse all the remaining options into the namespace
>>>   # store any unrecognized options on the object, so that the top
>>>   # level parser can decide what to do with them
>>> -namespace, arg_strings = parser.parse_known_args(arg_strings,
>>> namespace)
>>> +
>>> +# In case this subparser defines new defaults, we parse them
>>> +# in a new namespace object and then update the original
>>> +# namespace for the relevant parts.
>>> +subnamespace, arg_strings = parser.parse_known_args(arg_strings,
>>> None)
>>> +for key, value in vars(subnamespace).items():
>>> +setattr(namespace, key, value)
>>> +
>>>   if arg_strings:
>>>   vars(namespace).setdefault(_UNRECOGNIZED_ARGS_ATTR, [])
>>>   getattr(namespace, _UNRECOGNIZED_ARGS_ATTR).
>>> extend(arg_strings)
>>> ---
>>>
>>> Which is related to http://bugs.python.org/issue9351
>>>
>>> Maybe argparse just became more strict? I don't understand the issue.
>>>
>>
>> Steven Bethard, the argparse maintainer, defined the old behavior of
>> ignoring subparser defaults (where there are also top level defaults) as a
>> bug "counter to what people probably expect".  If the old behavior had been
>> documented, changing it in a bug-fix release would have been a mistake.
>> But looking at the patch, the doc seems to have been silent on the issue.
>>
>> This is not the first time someone considered a 'bug fix' to be a
>> 'regression', which it might be from their viewpoint.  The last comment on
>> the github thread suggests that an easy fix was found.
>>
>> --
>> 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/
>> guido%40python.org
>>
>
>
>
> --
> --Guido van Rossum (python.org/~guido)
>
> ___
> Python-Dev mailing list
> Python-Dev@python.org
> https://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe:
> https://mail.python.org/mailman/options/python-dev/rymg19%40gmail.com
>
>


-- 
Ryan
If anybody ever asks me why I prefer C++ to C, my answer will be simple:
"It's becauseslejfp23(@#Q*(E*EIdc-SEGFAULT. Wait, I don't think that was
nul-terminated."
Personal reality distortion fields are immune to contradictory evidence. -
srean
Check out my website: http://kirbyfan64.github.io/
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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

[Ryan Gonzalez]

On Thu, Jan 15, 2015 at 3:30 PM, Victor Stinner 
wrote:

> Hi,
>
> I installed the SP1 for Visual Studio 2010, and it looks like that it
> broke my Windows SDK 7.1 (setenv was missing, cl.exe was also
> missing). I uninstalled the SDK 7.1, and then I saw that a patch is
> required to use Windows SDK 7.1 with Visual Studio 2010 SP1. Ah. Too
> late.
>
> I don't understand the link between the SDK and Visual Studio. There
> are not separated directories?
>
> And now I cannot find Windows SDK 7.1 anymore. It looks like it
> disappeared from microsoft.com. The SDK 7.1 was released in 2010, so
> it's now quite old, but it worked well!
>

http://www.mathworks.com/matlabcentral/answers/101105-how-do-i-install-microsoft-windows-sdk-7-1
http://www.microsoft.com/en-us/download/details.aspx?id=8279

Both are about Windows SDK 7.1. The latter is a download link; the former
says what to do if you have VS 2010 installed.


>
> Can I use the SDK 8.0 or 8.1 to build Python extensions for Python 3.3 and
> 3.4?
>
> It took me several hours to have a working platform to build my Python
> extensions for Python 2.7, 3.3 and 3.4, in 32 and 64 bits with
> automated scripts to run all commands. And now it doesn't work anymore
> :-(
>
> Victor
>
> 2015-01-13 23:46 GMT+01:00 M.-A. Lemburg :
> > On 13.01.2015 23:42, Brian Curtin wrote:
> >> On Tue, Jan 13, 2015 at 4:36 PM, Victor Stinner
> >>  wrote:
> >>> 2015-01-13 23:18 GMT+01:00 Steve Dower :
>  Technically, Python 3.5 requires Visual Studio 2015
> >>>
> >>> For me, it's *very* difficult to find how to install Visual Studio.
> >>> There are many different websites and web pages which mention Visual
> >>> Studio with a lot of versions and "flavors" (Express, Community,
> >>> Ultimate, etc.).
> >>>
> >>> Visual Studio 2015 was not released yet :-/
> >>>
> >>> My VM has only a disk of 40 GB. Only 12 GB are free. I already have VS
> >>> 2008 Express and VS 2010 Express installed. I understood that
> >>> "Ultimate" includes a *lot* of things, not only a C compiler.
> >>>
> >>> I found a "free" Visual Studio which is in fact Visual Studio 2013
> >>> Community and I read that it's not free.
> >>>
> >>> I sent an email to Brian Curtin to ask to renew my MSDN account. He
> >>> didn't reply yet.
> >>
> >> I saw that and will send it on, but it's still going to take some time
> >> to process - usually a week or so.
> >>
> >> In the meantime, the first result searching for Visual Studio 2015
> >> came up with
> http://www.visualstudio.com/en-us/downloads/visual-studio-2015-downloads-vs.aspx
> ,
> >> which seems to give you VS2015. I haven't tried to run it since I'm
> >> not on Windows at the moment, but it looks correct.
> >
> > Just a note of caution: for older preview releases of VS the
> > only way to get back to a clean system was to reinstall
> > Windows.
> >
> > I don't know whether this will be different with VS 2015,
> > but if you care for your VM, you should probably create
> > a snapshot before installing VS 2015 preview to make it
> > easy to revert back, e.g. to install the final VS 2015
> > version.
> >
> > --
> > Marc-Andre Lemburg
> > eGenix.com
> >
> > Professional Python Services directly from the Source  (#1, Jan 13 2015)
>  Python Projects, Coaching and Consulting ...  http://www.egenix.com/
>  mxODBC Plone/Zope Database Adapter ...   http://zope.egenix.com/
>  mxODBC, mxDateTime, mxTextTools ...http://python.egenix.com/
> > 
> > 2015-01-09: Released eGenix pyOpenSSL 0.13.7 ...  http://egenix.com/go68
> > 2015-01-20: Python Meeting Duesseldorf ...http://egenix.com/go69
> >
> > : Try our mxODBC.Connect Python Database Interface for free ! ::
> >
> >eGenix.com Software, Skills and Services GmbH  Pastor-Loeh-Str.48
> > D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg
> >Registered at Amtsgericht Duesseldorf: HRB 46611
> >http://www.egenix.com/company/contact/
> ___
> 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/rymg19%40gmail.com
>



-- 
Ryan
If anybody ever asks me why I prefer C++ to C, my answer will be simple:
"It's becauseslejfp23(@#Q*(E*EIdc-SEGFAULT. Wait, I don't think that was
nul-terminated."
Personal reality distortion fields are immune to contradictory evidence. -
srean
Check out my website: http://kirbyfan64.github.io/
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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

[Ryan Gonzalez]

If you expand the Details section, it says the version is 7.1.

On Thu, Jan 15, 2015 at 3:58 PM, Victor Stinner 
wrote:

> 2015-01-15 22:39 GMT+01:00 Ryan Gonzalez :
> > http://www.microsoft.com/en-us/download/details.aspx?id=8279
>
> "Microsoft Windows SDK for Windows 7 and .NET Framework 4"
>
> Are you sure that it is SDK 7.1, and not 7.0?
>
> --
>
> The SDK 7.0 works for Python 2.7 which is compiled with Visual Studio 2008.
>
> I used the SDK 7.1 for Python 3.3 and 3.4 which are compiled with
> Visual Studio 2010.
>
> It looks likt SDK 8 is more for Visual Studio 2012.
>
> If you use the wrong SDK, you will depend on a "MSVCRxxx.dll" which is
> not provided by Python x.x (ex: MSVCR100.dll for SDK 7.1/Python 3.3 &
> 3.4).
>
> Victor
>



-- 
Ryan
If anybody ever asks me why I prefer C++ to C, my answer will be simple:
"It's becauseslejfp23(@#Q*(E*EIdc-SEGFAULT. Wait, I don't think that was
nul-terminated."
Personal reality distortion fields are immune to contradictory evidence. -
srean
Check out my website: http://kirbyfan64.github.io/
___
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()?

[Ryan Gonzalez]

Looking at pydoc.py, it looks like the Tk is purely optional...and isn't
called from the interpreter. (I'm not a core dev, though, so take that with
a grain of salt.) However, can't you just strip out the gui function and
the one place in the file where it's called?

Again, not a main Python developer, so don't take this too seriously!

On Mon, Jan 26, 2015 at 12:49 PM, Cyd Haselton  wrote:

> Hello,
> I've finally managed to build a (somewhat) working Python port for the
> Android tablet I'm using.  Unfortunately, as I quickly found out,
> Python's built-in help function requires tkinter, which requires
> tcl/tk.
>
> I did download the sources for tcl/tk and built tcl, but found out
> that tk requires XWindows libraries and includes.
>
> Long story short:  Is there an alternative documentation system (i.e.
> epydoc) that does not have tkinter dependencies?  If so, is there a
> parameter or env variable that would allow me to use it instead of
> pydoc?
>
> Thanks in advance,
> Cyd
> ___
> 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/rymg19%40gmail.com
>



-- 
Ryan
If anybody ever asks me why I prefer C++ to C, my answer will be simple:
"It's becauseslejfp23(@#Q*(E*EIdc-SEGFAULT. Wait, I don't think that was
nul-terminated."
Personal reality distortion fields are immune to contradictory evidence. -
srean
Check out my website: http://kirbyfan64.github.io/
___
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] Newly Built Python3 Binary Throws Segfault

[Ryan Gonzalez]

On Wed, Jan 28, 2015 at 10:43 AM, Guido van Rossum  wrote:

> What I see in the strace:
>
> ... load libpython3.4m.so.1.0
> ... load libm
> ... open /dev/__properties__ and do something to it (what?)
> ... get current time
> ... allocate memory
> ... getuid
> ... segfault
>
> That's not a lot to go on, but it doesn't look as if it has started to
> load modules yet.
>
> Does /dev/__properties__ ring a bell? Not to me.
>
>
https://android.googlesource.com/platform/system/core/+/tools_r22/init/property_service.c
is the code that works with that file.

This

explains
it a bit (slides 24-29). Looks like something to do with interprocess
communication. Likely has nothing to do with Python itself.

Maybe this

would
be useful?


> That stack trace would be really helpful.
>
> On Wed, Jan 28, 2015 at 8:34 AM, Cyd Haselton  wrote:
>
>> Apologies...I'm not sure what a stack track is, but I do have the
>> strace.  Nearest I can tell, it happens due to an open call, though I
>> am probably wrong.
>> Attaching the strace output to this email.  I'm going to head back to
>> the documentation and to back out of some Android-related changes in
>> _localemodule.c
>>
>> On Wed, Jan 28, 2015 at 9:43 AM, Guido van Rossum 
>> wrote:
>> > There could be a million differences relevant (unicode, ints, ...).
>> Perhaps
>> > the importlib bootstrap is failing. Perhaps the dynamic loading code
>> > changed. Did you get a stack track? (IIRC strace shows a syscall trace
>> --
>> > also useful, but doesn't tell you precisely how it segfaulted.)
>> >
>> > On Wed, Jan 28, 2015 at 6:43 AM, Cyd Haselton 
>> wrote:
>> >>
>> >> All,
>> >> I recently ditched my attempts to port Python 2.7.8 to Android in
>> >> favor of Python 3.4.2.  Unfortunately, after using the same configure
>> >> options in the same environment, and modifying the setup.py as needed,
>> >> the newly built binary throws a segfault when the generate-posix-vars
>> >> portion of the build is reached...and when it is run as well (i.e.
>> >> ./python --help, ./python -E -S -m sysconfig, or similar)
>> >>
>> >> I took a strace of ./python, however I'm a bit lost when reviewing it.
>> >> Any ideas as to what may be going on...i.e. why Python 2.7 works but
>> >> 3.x throws a segfault?
>> >>
>> >> Thanks in advance,
>> >> Cyd
>> >> ___
>> >> 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/guido%40python.org
>> >
>> >
>> >
>> >
>> > --
>> > --Guido van Rossum (python.org/~guido)
>>
>
>
>
> --
> --Guido van Rossum (python.org/~guido)
>
> ___
> Python-Dev mailing list
> Python-Dev@python.org
> https://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe:
> https://mail.python.org/mailman/options/python-dev/rymg19%40gmail.com
>
>


-- 
Ryan
If anybody ever asks me why I prefer C++ to C, my answer will be simple:
"It's becauseslejfp23(@#Q*(E*EIdc-SEGFAULT. Wait, I don't think that was
nul-terminated."
Personal reality distortion fields are immune to contradictory evidence. -
srean
Check out my website: http://kirbyfan64.github.io/
___
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] Newly Built Python3 Binary Throws Segfault

[Ryan Gonzalez]

Is it possible at all to get a stack trace of the crash using gdb? Try the
steps here <http://stackoverflow.com/a/10539883/2097780>.

That way we can see where Python's own strdup function is getting called.

On Fri, Jan 30, 2015 at 9:05 AM, Cyd Haselton  wrote:

> Absolutely.  Good thing I have addr2line on device
>
> /bld/python/Python-3.4.2 $ addr2line -C -f -e /lib/libpython3.4m.so.1.0
> 0008bbc8
> _PyMem_RawStrdup
> /bld/python/Python-3.4.2/Objects/obmalloc.c:323
> /bld/python/Python-3.4.2 $
>
>
>
> On Thu, Jan 29, 2015 at 8:26 PM, Ryan  wrote:
> > Could you try the steps at http://stackoverflow.com/a/11369475/2097780?
> They
> > allow you to get a better idea of where libc is crashing.
> >
> > Cyd Haselton  wrote:
> >>
> >> Managed to get this out of logcat:
> >> F(11914) Fatal signal 11 (SIGSEGV) at 0x (code=1), thread
> >> 11914 (python)  (libc)
> >>
> >> [ 01-29 19:30:55.855 23373:23373 F/libc ]
> >> Fatal signal 11 (SIGSEGV) at 0x (code=1), thread 23373 (python)
> >>
> >> Less detail than strace but it seems to be that python is segfaulting
> >> libc...
> >>
> >> On Wed, Jan 28, 2015 at 11:23 AM, Ryan Gonzalez 
> wrote:
> >>>
> >>>  On Wed, Jan 28, 2015 at 10:43 AM, Guido van Rossum 
> >>> wrote:
> >>>>
> >>>>
> >>>>  What I see in the strace:
> >>>>
> >>>>  ... load libpython3.4m.so.1.0
> >>>>  ... load libm
> >>>>  ... open /dev/__properties__ and do something to it
> >>>> (what?)
> >>>>  ... get current time
> >>>>  ... allocate memory
> >>>>  ... getuid
> >>>>  ... segfault
> >>>>
> >>>>  That's not a lot to go on, but it doesn't look as if it has started
> to
> >>>>  load modules yet.
> >>>>
> >>>>  Does /dev/__properties__ ring a bell? Not to me.
> >>>
> >>>
> >>>
> >>>
> >>>
> https://android.googlesource.com/platform/system/core/+/tools_r22/init/property_service.c
> >>>  is the code that works with that file.
> >>>
> >>>  This explains it a bit (slides 24-29). Looks like something to do with
> >>>  interprocess communication. Likely has nothing to do with Python
> itself.
> >>>
> >>>  Maybe this would be useful?
> >>>
> >>>>
> >>>>  That stack trace would be really helpful.
> >>>>
> >>>>  On Wed, Jan 28, 2015 at 8:34 AM, Cyd Haselton 
> >>>> wrote:
> >>>>>
> >>>>>
> >>>>>  Apologies...I'm not sure what a stack track is, but I do have the
> >>>>>  strace.  Nearest I can tell, it happens due to an open call, though
> I
> >>>>>  am probably wrong.
> >>>>>  Attaching the strace output to this email.  I'm going to head back
> to
> >>>>>  the documentation and to back out of some Android-related changes in
> >>>>>  _localemodule.c
> >>>>>
> >>>>>  On Wed, Jan 28, 2015 at 9:43 AM, Guido van Rossum  >
> >>>>>  wrote:
> >>>>>>
> >>>>>>  There could be a million differences relevant (unicode, ints, ...).
> >>>>>>  Perhaps
> >>>>>>  the importlib bootstrap is failing. Perhaps the dynamic loading
> code
> >>>>>>  changed. Did you get a stack track? (IIRC strace shows a syscall
> >>>>>> trace
> >>>>>>  --
> >>>>>>  also useful, but doesn't tell you precisely how
> >>>>>> it segfaulted.)
> >>>>>>
> >>>>>>  On Wed, Jan 28, 2015 at 6:43 AM, Cyd Haselton  >
> >>>>>>  wrote:
> >>>>>>>
> >>>>>>>
> >>>>>>>  All,
> >>>>>>>  I recently ditched my attempts to port Python 2.7.8 to Android in
> >>>>>>>  favor of Python 3.4.2.  Unfortunately, after using the same
> >>>>>>> configure
> >>>>>>>  options in the same environment, and modifying the setup.py as
> >>>>>>> needed,
> >>>>>>>  the newly built binary throws a segfault when the
> >>>>>>> generate-posix-vars
> >&g

Re: [Python-Dev] Newly Built Python3 Binary Throws Segfault

[Ryan Gonzalez]

I seriously doubt the issue is in that file; _PyMem_RawStrdup crashes when
calling strlen. It's that whatever is calling it is likely asking it to
duplicate a null pointer. Basically, it's probably the caller's fault.

You could always try modifying _PyMem_RawStrdup to return NULL when given a
null pointer and see where it then segfaults.

On Fri, Jan 30, 2015 at 11:53 AM, Cyd Haselton  wrote:

> Alternatively, is there a hassle-free way to find out what changed in
> obmalloc.c between 2.7.x and 3.4.x?
>
>
> On Fri, Jan 30, 2015 at 9:29 AM, Cyd Haselton  wrote:
> > There's a related strdup patch for readline.c, mentioned
> > here:http://bugs.python.org/issue21390 and here
> > https://github.com/rave-engine/python3-android/issues/2.
> > There's a patch, but I'm not sure how to modify it for obmalloc.c, as
> > (I think) the functions all belong to Python...they're all prefixed
> > with _PyXx
> >
> > On Fri, Jan 30, 2015 at 9:05 AM, Cyd Haselton 
> wrote:
> >> Absolutely.  Good thing I have addr2line on device
> >>
> >> /bld/python/Python-3.4.2 $ addr2line -C -f -e /lib/libpython3.4m.so.1.0
> 0008bbc8
> >> _PyMem_RawStrdup
> >> /bld/python/Python-3.4.2/Objects/obmalloc.c:323
> >> /bld/python/Python-3.4.2 $
> >>
> >>
> >>
> >> On Thu, Jan 29, 2015 at 8:26 PM, Ryan  wrote:
> >>> Could you try the steps at http://stackoverflow.com/a/11369475/2097780?
> They
> >>> allow you to get a better idea of where libc is crashing.
> >>>
> >>> Cyd Haselton  wrote:
> >>>>
> >>>> Managed to get this out of logcat:
> >>>> F(11914) Fatal signal 11 (SIGSEGV) at 0x (code=1), thread
> >>>> 11914 (python)  (libc)
> >>>>
> >>>> [ 01-29 19:30:55.855 23373:23373 F/libc ]
> >>>> Fatal signal 11 (SIGSEGV) at 0x (code=1), thread 23373
> (python)
> >>>>
> >>>> Less detail than strace but it seems to be that python is segfaulting
> >>>> libc...
> >>>>
> >>>> On Wed, Jan 28, 2015 at 11:23 AM, Ryan Gonzalez 
> wrote:
> >>>>>
> >>>>>  On Wed, Jan 28, 2015 at 10:43 AM, Guido van Rossum <
> gu...@python.org>
> >>>>> wrote:
> >>>>>>
> >>>>>>
> >>>>>>  What I see in the strace:
> >>>>>>
> >>>>>>  ... load libpython3.4m.so.1.0
> >>>>>>  ... load libm
> >>>>>>  ... open /dev/__properties__ and do something to it
> >>>>>> (what?)
> >>>>>>  ... get current time
> >>>>>>  ... allocate memory
> >>>>>>  ... getuid
> >>>>>>  ... segfault
> >>>>>>
> >>>>>>  That's not a lot to go on, but it doesn't look as if it has
> started to
> >>>>>>  load modules yet.
> >>>>>>
> >>>>>>  Does /dev/__properties__ ring a bell? Not to me.
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> https://android.googlesource.com/platform/system/core/+/tools_r22/init/property_service.c
> >>>>>  is the code that works with that file.
> >>>>>
> >>>>>  This explains it a bit (slides 24-29). Looks like something to do
> with
> >>>>>  interprocess communication. Likely has nothing to do with Python
> itself.
> >>>>>
> >>>>>  Maybe this would be useful?
> >>>>>
> >>>>>>
> >>>>>>  That stack trace would be really helpful.
> >>>>>>
> >>>>>>  On Wed, Jan 28, 2015 at 8:34 AM, Cyd Haselton  >
> >>>>>> wrote:
> >>>>>>>
> >>>>>>>
> >>>>>>>  Apologies...I'm not sure what a stack track is, but I do have the
> >>>>>>>  strace.  Nearest I can tell, it happens due to an open call,
> though I
> >>>>>>>  am probably wrong.
> >>>>>>>  Attaching the strace output to this email.  I'm going to head
> back to
> >>>>>>>  the documentation and to back out of some Android-related changes
> in
> >>>>>>>  _localemodule.c
> >>>>>>>
> >>>>>&

Re: [Python-Dev] Newly Built Python3 Binary Throws Segfault

[Ryan Gonzalez]

No...

...but I think I found the issue with grep. Try applying the attached patch
to the Python/frozenmain.c. It comments out the locale handling.

It seems that Python always calls its strdup function on the locale string.
On Android, this can apparently be null (as seen in the bug report you
linked to).

On Fri, Jan 30, 2015 at 12:00 PM, Cyd Haselton  wrote:

> I don't have gdb on device; does the following tell you where Python's
> strdup is called?
>
> >> _PyMem_RawStrdup
> >> /bld/python/Python-3.4.2/Objects/obmalloc.c:323
>
> On Fri, Jan 30, 2015 at 11:52 AM, Ryan Gonzalez  wrote:
> > Is it possible at all to get a stack trace of the crash using gdb? Try
> the
> > steps here.
> >
> > That way we can see where Python's own strdup function is getting called.
> >
> > On Fri, Jan 30, 2015 at 9:05 AM, Cyd Haselton 
> wrote:
> >>
> >> Absolutely.  Good thing I have addr2line on device
> >>
> >> /bld/python/Python-3.4.2 $ addr2line -C -f -e /lib/libpython3.4m.so.1.0
> >> 0008bbc8
> >> _PyMem_RawStrdup
> >> /bld/python/Python-3.4.2/Objects/obmalloc.c:323
> >> /bld/python/Python-3.4.2 $
> >>
> >>
> >>
> >> On Thu, Jan 29, 2015 at 8:26 PM, Ryan  wrote:
> >> > Could you try the steps at
> http://stackoverflow.com/a/11369475/2097780?
> >> > They
> >> > allow you to get a better idea of where libc is crashing.
> >> >
> >> > Cyd Haselton  wrote:
> >> >>
> >> >> Managed to get this out of logcat:
> >> >> F(11914) Fatal signal 11 (SIGSEGV) at 0x (code=1), thread
> >> >> 11914 (python)  (libc)
> >> >>
> >> >> [ 01-29 19:30:55.855 23373:23373 F/libc ]
> >> >> Fatal signal 11 (SIGSEGV) at 0x (code=1), thread 23373
> (python)
> >> >>
> >> >> Less detail than strace but it seems to be that python is segfaulting
> >> >> libc...
> >> >>
> >> >> On Wed, Jan 28, 2015 at 11:23 AM, Ryan Gonzalez 
> >> >> wrote:
> >> >>>
> >> >>>  On Wed, Jan 28, 2015 at 10:43 AM, Guido van Rossum <
> gu...@python.org>
> >> >>> wrote:
> >> >>>>
> >> >>>>
> >> >>>>  What I see in the strace:
> >> >>>>
> >> >>>>  ... load libpython3.4m.so.1.0
> >> >>>>  ... load libm
> >> >>>>  ... open /dev/__properties__ and do something to it
> >> >>>> (what?)
> >> >>>>  ... get current time
> >> >>>>  ... allocate memory
> >> >>>>  ... getuid
> >> >>>>  ... segfault
> >> >>>>
> >> >>>>  That's not a lot to go on, but it doesn't look as if it has
> started
> >> >>>> to
> >> >>>>  load modules yet.
> >> >>>>
> >> >>>>  Does /dev/__properties__ ring a bell? Not to me.
> >> >>>
> >> >>>
> >> >>>
> >> >>>
> >> >>>
> >> >>>
> https://android.googlesource.com/platform/system/core/+/tools_r22/init/property_service.c
> >> >>>  is the code that works with that file.
> >> >>>
> >> >>>  This explains it a bit (slides 24-29). Looks like something to do
> >> >>> with
> >> >>>  interprocess communication. Likely has nothing to do with Python
> >> >>> itself.
> >> >>>
> >> >>>  Maybe this would be useful?
> >> >>>
> >> >>>>
> >> >>>>  That stack trace would be really helpful.
> >> >>>>
> >> >>>>  On Wed, Jan 28, 2015 at 8:34 AM, Cyd Haselton <
> chasel...@gmail.com>
> >> >>>> wrote:
> >> >>>>>
> >> >>>>>
> >> >>>>>  Apologies...I'm not sure what a stack track is, but I do have the
> >> >>>>>  strace.  Nearest I can tell, it happens due to an open call,
> though
> >> >>>>> I
> >> >>>>>  am probably wrong.
> >> >>>>>  Attaching the strace output to this email.  I'm going to head
> back
> >> >>>>> to
> >> >>>>>  the documentation and to back out of s

Re: [Python-Dev] Newly Built Python3 Binary Throws Segfault

[Ryan Gonzalez]

No, it returns NULL if malloc gives it a raw pointer. It unconditionally
checks the length of the (possibly null) string argument first.

Please try the patch I attached in the last email. It *might* fix the
issue. Android has crappy locale handling.

On Fri, Jan 30, 2015 at 12:09 PM, Cyd Haselton  wrote:

>   Unless i'm reading something incorrectly,  _PyMem_RawStrdup is
> currently returning NULL when given a null pointer.
>
> From obmalloc.c
>
> _PyMem_RawStrdup(const char *str)
> {
> size_t size;
> char *copy;
> size = strlen(str) + 1;
> copy = PyMem_RawMalloc(size);
> if (copy == NULL)
> return NULL;
> memcpy(copy, str, size);
> return copy;
>   }
>
> On Fri, Jan 30, 2015 at 11:56 AM, Ryan Gonzalez  wrote:
> > I seriously doubt the issue is in that file; _PyMem_RawStrdup crashes
> when
> > calling strlen. It's that whatever is calling it is likely asking it to
> > duplicate a null pointer. Basically, it's probably the caller's fault.
> >
> > You could always try modifying _PyMem_RawStrdup to return NULL when
> given a
> > null pointer and see where it then segfaults.
> >
> > On Fri, Jan 30, 2015 at 11:53 AM, Cyd Haselton 
> wrote:
> >>
> >> Alternatively, is there a hassle-free way to find out what changed in
> >> obmalloc.c between 2.7.x and 3.4.x?
> >>
> >>
> >> On Fri, Jan 30, 2015 at 9:29 AM, Cyd Haselton 
> wrote:
> >> > There's a related strdup patch for readline.c, mentioned
> >> > here:http://bugs.python.org/issue21390 and here
> >> > https://github.com/rave-engine/python3-android/issues/2.
> >> > There's a patch, but I'm not sure how to modify it for obmalloc.c, as
> >> > (I think) the functions all belong to Python...they're all prefixed
> >> > with _PyXx
> >> >
> >> > On Fri, Jan 30, 2015 at 9:05 AM, Cyd Haselton 
> >> > wrote:
> >> >> Absolutely.  Good thing I have addr2line on device
> >> >>
> >> >> /bld/python/Python-3.4.2 $ addr2line -C -f -e
> /lib/libpython3.4m.so.1.0
> >> >> 0008bbc8
> >> >> _PyMem_RawStrdup
> >> >> /bld/python/Python-3.4.2/Objects/obmalloc.c:323
> >> >> /bld/python/Python-3.4.2 $
> >> >>
> >> >>
> >> >>
> >> >> On Thu, Jan 29, 2015 at 8:26 PM, Ryan  wrote:
> >> >>> Could you try the steps at
> >> >>> http://stackoverflow.com/a/11369475/2097780? They
> >> >>> allow you to get a better idea of where libc is crashing.
> >> >>>
> >> >>> Cyd Haselton  wrote:
> >> >>>>
> >> >>>> Managed to get this out of logcat:
> >> >>>> F(11914) Fatal signal 11 (SIGSEGV) at 0x (code=1), thread
> >> >>>> 11914 (python)  (libc)
> >> >>>>
> >> >>>> [ 01-29 19:30:55.855 23373:23373 F/libc ]
> >> >>>> Fatal signal 11 (SIGSEGV) at 0x (code=1), thread 23373
> >> >>>> (python)
> >> >>>>
> >> >>>> Less detail than strace but it seems to be that python is
> segfaulting
> >> >>>> libc...
> >> >>>>
> >> >>>> On Wed, Jan 28, 2015 at 11:23 AM, Ryan Gonzalez 
> >> >>>> wrote:
> >> >>>>>
> >> >>>>>  On Wed, Jan 28, 2015 at 10:43 AM, Guido van Rossum
> >> >>>>> 
> >> >>>>> wrote:
> >> >>>>>>
> >> >>>>>>
> >> >>>>>>  What I see in the strace:
> >> >>>>>>
> >> >>>>>>  ... load libpython3.4m.so.1.0
> >> >>>>>>  ... load libm
> >> >>>>>>  ... open /dev/__properties__ and do something to it
> >> >>>>>> (what?)
> >> >>>>>>  ... get current time
> >> >>>>>>  ... allocate memory
> >> >>>>>>  ... getuid
> >> >>>>>>  ... segfault
> >> >>>>>>
> >> >>>>>>  That's not a lot to go on, but it doesn't look as if it has
> >> >>>>>> started to
> >> >>>>>>  load modules yet.
> >> >>>>>>
> >> >>>>>>  Does /dev/__prope

Re: [Python-Dev] Newly Built Python3 Binary Throws Segfault

[Ryan Gonzalez]

Are you sure the patch was applied correctly? I was SO sure it would work!

FYI, you tried the patch I attached to the email message, right?

On Fri, Jan 30, 2015 at 12:58 PM, Cyd Haselton  wrote:

> Update:  I did try the patch after getting it installed correctly, but
> I'm still getting a segfault on the newly built binary.
> Will post info this afternoon.
>
> On Fri, Jan 30, 2015 at 12:10 PM, Ryan Gonzalez  wrote:
> > No, it returns NULL if malloc gives it a raw pointer. It unconditionally
> > checks the length of the (possibly null) string argument first.
> >
> > Please try the patch I attached in the last email. It *might* fix the
> issue.
> > Android has crappy locale handling.
> >
> > On Fri, Jan 30, 2015 at 12:09 PM, Cyd Haselton 
> wrote:
> >>
> >>   Unless i'm reading something incorrectly,  _PyMem_RawStrdup is
> >> currently returning NULL when given a null pointer.
> >>
> >> From obmalloc.c
> >>
> >> _PyMem_RawStrdup(const char *str)
> >> {
> >> size_t size;
> >> char *copy;
> >> size = strlen(str) + 1;
> >> copy = PyMem_RawMalloc(size);
> >> if (copy == NULL)
> >> return NULL;
> >> memcpy(copy, str, size);
> >> return copy;
> >>   }
> >>
> >> On Fri, Jan 30, 2015 at 11:56 AM, Ryan Gonzalez 
> wrote:
> >> > I seriously doubt the issue is in that file; _PyMem_RawStrdup crashes
> >> > when
> >> > calling strlen. It's that whatever is calling it is likely asking it
> to
> >> > duplicate a null pointer. Basically, it's probably the caller's fault.
> >> >
> >> > You could always try modifying _PyMem_RawStrdup to return NULL when
> >> > given a
> >> > null pointer and see where it then segfaults.
> >> >
> >> > On Fri, Jan 30, 2015 at 11:53 AM, Cyd Haselton 
> >> > wrote:
> >> >>
> >> >> Alternatively, is there a hassle-free way to find out what changed in
> >> >> obmalloc.c between 2.7.x and 3.4.x?
> >> >>
> >> >>
> >> >> On Fri, Jan 30, 2015 at 9:29 AM, Cyd Haselton 
> >> >> wrote:
> >> >> > There's a related strdup patch for readline.c, mentioned
> >> >> > here:http://bugs.python.org/issue21390 and here
> >> >> > https://github.com/rave-engine/python3-android/issues/2.
> >> >> > There's a patch, but I'm not sure how to modify it for obmalloc.c,
> as
> >> >> > (I think) the functions all belong to Python...they're all prefixed
> >> >> > with _PyXx
> >> >> >
> >> >> > On Fri, Jan 30, 2015 at 9:05 AM, Cyd Haselton  >
> >> >> > wrote:
> >> >> >> Absolutely.  Good thing I have addr2line on device
> >> >> >>
> >> >> >> /bld/python/Python-3.4.2 $ addr2line -C -f -e
> >> >> >> /lib/libpython3.4m.so.1.0
> >> >> >> 0008bbc8
> >> >> >> _PyMem_RawStrdup
> >> >> >> /bld/python/Python-3.4.2/Objects/obmalloc.c:323
> >> >> >> /bld/python/Python-3.4.2 $
> >> >> >>
> >> >> >>
> >> >> >>
> >> >> >> On Thu, Jan 29, 2015 at 8:26 PM, Ryan  wrote:
> >> >> >>> Could you try the steps at
> >> >> >>> http://stackoverflow.com/a/11369475/2097780? They
> >> >> >>> allow you to get a better idea of where libc is crashing.
> >> >> >>>
> >> >> >>> Cyd Haselton  wrote:
> >> >> >>>>
> >> >> >>>> Managed to get this out of logcat:
> >> >> >>>> F(11914) Fatal signal 11 (SIGSEGV) at 0x (code=1),
> thread
> >> >> >>>> 11914 (python)  (libc)
> >> >> >>>>
> >> >> >>>> [ 01-29 19:30:55.855 23373:23373 F/libc ]
> >> >> >>>> Fatal signal 11 (SIGSEGV) at 0x (code=1), thread 23373
> >> >> >>>> (python)
> >> >> >>>>
> >> >> >>>> Less detail than strace but it seems to be that python is
> >> >> >>>> segfaulting
> >> >> >>>> libc...
> >> >> >>>>
> >> >> >>>

Re: [Python-Dev] Newly Built Python3 Binary Throws Segfault

[Ryan Gonzalez]

Do you have the Android SDK and NDK installed? If so...

Using Google, I've created this series of steps, which may (or may not)
work:

1. Make sure you have a copy of Python on your computer and make sure that
it's built with debug symbols.

2. Run the following commands from a shell with your phone plugged in:

  adb forward tcp:5039 tcp:5039
  adb shell /system/bin/gdbserver tcp:5039 
  /arm-linux-androideabi-gdb

Now, GDB should have opened, so type the following commands:

  set solib-search-path 
  file 
  target remote :5055
  run

Now, wait for the program to crash and type:

  backtrace

You should now see a complete backtrace in your terminal. To GDB, type:

  quit

*crosses fingers*

On Fri, Jan 30, 2015 at 2:50 PM, Cyd Haselton  wrote:

> Unfortunately it is still reporting the same function :-/.
>
> On Fri, Jan 30, 2015 at 1:44 PM, Ryan Gonzalez  wrote:
> > Yes...
> >
> > Can you check if it's crashing in a different function now?
> >
> > On Fri, Jan 30, 2015 at 1:39 PM, Cyd Haselton 
> wrote:
> >>
> >> Yes I did.  I did have to enter all the information in manually...I'm
> >> not familiar with automated patch application tools and even if I
> >> were, I'm pretty sure I wouldn't have them on my device.
> >>
> >> Just so that I'm absolutely sure I got everything correct...you wanted
> >> all of the lines in the patch commented out, correct?  Basically
> >> everything referencing oldloc?
> >>
> >> On Fri, Jan 30, 2015 at 1:00 PM, Ryan Gonzalez 
> wrote:
> >> > Are you sure the patch was applied correctly? I was SO sure it would
> >> > work!
> >> >
> >> > FYI, you tried the patch I attached to the email message, right?
> >> >
> >> > On Fri, Jan 30, 2015 at 12:58 PM, Cyd Haselton 
> >> > wrote:
> >> >>
> >> >> Update:  I did try the patch after getting it installed correctly,
> but
> >> >> I'm still getting a segfault on the newly built binary.
> >> >> Will post info this afternoon.
> >> >>
> >> >> On Fri, Jan 30, 2015 at 12:10 PM, Ryan Gonzalez 
> >> >> wrote:
> >> >> > No, it returns NULL if malloc gives it a raw pointer. It
> >> >> > unconditionally
> >> >> > checks the length of the (possibly null) string argument first.
> >> >> >
> >> >> > Please try the patch I attached in the last email. It *might* fix
> the
> >> >> > issue.
> >> >> > Android has crappy locale handling.
> >> >> >
> >> >> > On Fri, Jan 30, 2015 at 12:09 PM, Cyd Haselton <
> chasel...@gmail.com>
> >> >> > wrote:
> >> >> >>
> >> >> >>   Unless i'm reading something incorrectly,  _PyMem_RawStrdup is
> >> >> >> currently returning NULL when given a null pointer.
> >> >> >>
> >> >> >> From obmalloc.c
> >> >> >>
> >> >> >> _PyMem_RawStrdup(const char *str)
> >> >> >> {
> >> >> >> size_t size;
> >> >> >> char *copy;
> >> >> >> size = strlen(str) + 1;
> >> >> >> copy = PyMem_RawMalloc(size);
> >> >> >> if (copy == NULL)
> >> >> >> return NULL;
> >> >> >> memcpy(copy, str, size);
> >> >> >> return copy;
> >> >> >>   }
> >> >> >>
> >> >> >> On Fri, Jan 30, 2015 at 11:56 AM, Ryan Gonzalez  >
> >> >> >> wrote:
> >> >> >> > I seriously doubt the issue is in that file; _PyMem_RawStrdup
> >> >> >> > crashes
> >> >> >> > when
> >> >> >> > calling strlen. It's that whatever is calling it is likely
> asking
> >> >> >> > it
> >> >> >> > to
> >> >> >> > duplicate a null pointer. Basically, it's probably the caller's
> >> >> >> > fault.
> >> >> >> >
> >> >> >> > You could always try modifying _PyMem_RawStrdup to return NULL
> >> >> >> > when
> >> >> >> > given a
> >> >> >> > null pointer and see where it then segfaults.
> >> >> >> >
> >> >> >> > On Fri, Jan 30, 2015 at 11:5

Re: [Python-Dev] Newly Built Python3 Binary Throws Segfault

[Ryan Gonzalez]

Do you have just the SDK (which doesn't require Cygwin) or a rooted phone?
If so, I can upload instructions that don't use the NDK.

On Fri, Jan 30, 2015 at 6:19 PM, Cyd Haselton  wrote:

> This is going to take some time...here's why:
>
> Downloading and installing the NDK/SDK won't be too hard...I have to
> clear some space...but my primary machine is running Windows 7 and I'd
> rather swallow hot coals than install Cygwin.  I've got next to no
> experience with it, other than knowing that the NDK recommends against
> it.
>
> I've got a CentOS VM...but it's currently in tarball form on an
> external drive for space reasons...and it only has the NDK installed.
> If I am able to get it back up and running, there's still the task of
> getting  adb connected to my device. from the VM.
>
> Not saying it's impossible...just that it'll take time...and I'll
> probably have to tackle it tomorrow (earliest) or Sunday (latest).  In
> the meantime I'll also check to see if there's anything that can a)
> run in an Android terminal and b) can take a stack trace; it would be
> far, far, far easier than either option above.
>
>
>
> On Fri, Jan 30, 2015 at 4:19 PM, Ryan Gonzalez  wrote:
> > Do you have the Android SDK and NDK installed? If so...
> >
> > Using Google, I've created this series of steps, which may (or may not)
> > work:
> >
> > 1. Make sure you have a copy of Python on your computer and make sure
> that
> > it's built with debug symbols.
> >
> > 2. Run the following commands from a shell with your phone plugged in:
> >
> >   adb forward tcp:5039 tcp:5039
> >   adb shell /system/bin/gdbserver tcp:5039 
> >   /arm-linux-androideabi-gdb
> >
> > Now, GDB should have opened, so type the following commands:
> >
> >   set solib-search-path 
> >   file 
> >   target remote :5055
> >   run
> >
> > Now, wait for the program to crash and type:
> >
> >   backtrace
> >
> > You should now see a complete backtrace in your terminal. To GDB, type:
> >
> >   quit
> >
> > *crosses fingers*
> >
> > On Fri, Jan 30, 2015 at 2:50 PM, Cyd Haselton 
> wrote:
> >>
> >> Unfortunately it is still reporting the same function :-/.
> >>
> >> On Fri, Jan 30, 2015 at 1:44 PM, Ryan Gonzalez 
> wrote:
> >> > Yes...
> >> >
> >> > Can you check if it's crashing in a different function now?
> >> >
> >> > On Fri, Jan 30, 2015 at 1:39 PM, Cyd Haselton 
> >> > wrote:
> >> >>
> >> >> Yes I did.  I did have to enter all the information in manually...I'm
> >> >> not familiar with automated patch application tools and even if I
> >> >> were, I'm pretty sure I wouldn't have them on my device.
> >> >>
> >> >> Just so that I'm absolutely sure I got everything correct...you
> wanted
> >> >> all of the lines in the patch commented out, correct?  Basically
> >> >> everything referencing oldloc?
> >> >>
> >> >> On Fri, Jan 30, 2015 at 1:00 PM, Ryan Gonzalez 
> >> >> wrote:
> >> >> > Are you sure the patch was applied correctly? I was SO sure it
> would
> >> >> > work!
> >> >> >
> >> >> > FYI, you tried the patch I attached to the email message, right?
> >> >> >
> >> >> > On Fri, Jan 30, 2015 at 12:58 PM, Cyd Haselton <
> chasel...@gmail.com>
> >> >> > wrote:
> >> >> >>
> >> >> >> Update:  I did try the patch after getting it installed correctly,
> >> >> >> but
> >> >> >> I'm still getting a segfault on the newly built binary.
> >> >> >> Will post info this afternoon.
> >> >> >>
> >> >> >> On Fri, Jan 30, 2015 at 12:10 PM, Ryan Gonzalez  >
> >> >> >> wrote:
> >> >> >> > No, it returns NULL if malloc gives it a raw pointer. It
> >> >> >> > unconditionally
> >> >> >> > checks the length of the (possibly null) string argument first.
> >> >> >> >
> >> >> >> > Please try the patch I attached in the last email. It *might*
> fix
> >> >> >> > the
> >> >> >> > issue.
> >> >> >> > Android has crappy locale handling.
> >> >

Re: [Python-Dev] Newly Built Python3 Binary Throws Segfault

[Ryan Gonzalez]

Regardless, if you're looking to toy more with stuff like this, I'd highly
recommend dual-booting with Ubuntu, which is what I'm doing now. (Now I
rarely ever boot into Windows!)

On Fri, Jan 30, 2015 at 7:51 PM, Ryan Gonzalez  wrote:

> Do you have just the SDK (which doesn't require Cygwin) or a rooted phone?
> If so, I can upload instructions that don't use the NDK.
>
> On Fri, Jan 30, 2015 at 6:19 PM, Cyd Haselton  wrote:
>
>> This is going to take some time...here's why:
>>
>> Downloading and installing the NDK/SDK won't be too hard...I have to
>> clear some space...but my primary machine is running Windows 7 and I'd
>> rather swallow hot coals than install Cygwin.  I've got next to no
>> experience with it, other than knowing that the NDK recommends against
>> it.
>>
>> I've got a CentOS VM...but it's currently in tarball form on an
>> external drive for space reasons...and it only has the NDK installed.
>> If I am able to get it back up and running, there's still the task of
>> getting  adb connected to my device. from the VM.
>>
>> Not saying it's impossible...just that it'll take time...and I'll
>> probably have to tackle it tomorrow (earliest) or Sunday (latest).  In
>> the meantime I'll also check to see if there's anything that can a)
>> run in an Android terminal and b) can take a stack trace; it would be
>> far, far, far easier than either option above.
>>
>>
>>
>> On Fri, Jan 30, 2015 at 4:19 PM, Ryan Gonzalez  wrote:
>> > Do you have the Android SDK and NDK installed? If so...
>> >
>> > Using Google, I've created this series of steps, which may (or may not)
>> > work:
>> >
>> > 1. Make sure you have a copy of Python on your computer and make sure
>> that
>> > it's built with debug symbols.
>> >
>> > 2. Run the following commands from a shell with your phone plugged in:
>> >
>> >   adb forward tcp:5039 tcp:5039
>> >   adb shell /system/bin/gdbserver tcp:5039 
>> >   /arm-linux-androideabi-gdb
>> >
>> > Now, GDB should have opened, so type the following commands:
>> >
>> >   set solib-search-path 
>> >   file 
>> >   target remote :5055
>> >   run
>> >
>> > Now, wait for the program to crash and type:
>> >
>> >   backtrace
>> >
>> > You should now see a complete backtrace in your terminal. To GDB, type:
>> >
>> >   quit
>> >
>> > *crosses fingers*
>> >
>> > On Fri, Jan 30, 2015 at 2:50 PM, Cyd Haselton 
>> wrote:
>> >>
>> >> Unfortunately it is still reporting the same function :-/.
>> >>
>> >> On Fri, Jan 30, 2015 at 1:44 PM, Ryan Gonzalez 
>> wrote:
>> >> > Yes...
>> >> >
>> >> > Can you check if it's crashing in a different function now?
>> >> >
>> >> > On Fri, Jan 30, 2015 at 1:39 PM, Cyd Haselton 
>> >> > wrote:
>> >> >>
>> >> >> Yes I did.  I did have to enter all the information in
>> manually...I'm
>> >> >> not familiar with automated patch application tools and even if I
>> >> >> were, I'm pretty sure I wouldn't have them on my device.
>> >> >>
>> >> >> Just so that I'm absolutely sure I got everything correct...you
>> wanted
>> >> >> all of the lines in the patch commented out, correct?  Basically
>> >> >> everything referencing oldloc?
>> >> >>
>> >> >> On Fri, Jan 30, 2015 at 1:00 PM, Ryan Gonzalez 
>> >> >> wrote:
>> >> >> > Are you sure the patch was applied correctly? I was SO sure it
>> would
>> >> >> > work!
>> >> >> >
>> >> >> > FYI, you tried the patch I attached to the email message, right?
>> >> >> >
>> >> >> > On Fri, Jan 30, 2015 at 12:58 PM, Cyd Haselton <
>> chasel...@gmail.com>
>> >> >> > wrote:
>> >> >> >>
>> >> >> >> Update:  I did try the patch after getting it installed
>> correctly,
>> >> >> >> but
>> >> >> >> I'm still getting a segfault on the newly built binary.
>> >> >> >> Will post info this afternoon.
>> >> >> >>
>> >> >>

Re: [Python-Dev] Newly Built Python3 Binary Throws Segfault

[Ryan Gonzalez]

That looks better! Looks like now the real encoding issues are coming up.
Try going to line 269 of pythonrun.c and changing:

PyErr_SetNone(PyExc_NotImplementedError);
return NULL;

to:

char* m = malloc(6);
strcpy(m, "ascii");
return m;

This just sets a default encoding.

On Sat, Jan 31, 2015 at 1:21 PM, Cyd Haselton  wrote:

> Very interesting. I got this error
>
> Fatal Python error: Py_Initialize: Unable to get the locale encoding
> NotImplementedError
> Aborted
> generate-posix-vars failed
> make: *** [pybuilddir.txt] Error 1
>
> ...but it didn't (of course) segfault. I'll pull gdb, get the results and
> send them.
>
> On January 31, 2015 1:10:18 PM CST, Ryan  wrote:
>
>> No; I was looking for all uses of _PyRaw_Strdup. Surprisingly, it's used
>> only a few times.
>>
>> Cyd Haselton  wrote:
>>>
>>> Question:
>>> When you said earlier that you found the problem by using grep...were
>>> you looking for places where strdup called locale?
>>>
>>> On January 30, 2015 7:52:47 PM CST, Ryan Gonzalez 
>>> wrote:
>>>>
>>>> Regardless, if you're looking to toy more with stuff like this, I'd
>>>> highly recommend dual-booting with Ubuntu, which is what I'm doing now.
>>>> (Now I rarely ever boot into Windows!)
>>>>
>>>> On Fri, Jan 30, 2015 at 7:51 PM, Ryan Gonzalez 
>>>> wrote:
>>>>
>>>>> Do you have just the SDK (which doesn't require Cygwin) or a rooted
>>>>> phone? If so, I can upload instructions that don't use the NDK.
>>>>>
>>>>> On Fri, Jan 30, 2015 at 6:19 PM, Cyd Haselton 
>>>>> wrote:
>>>>>
>>>>>> This is going to take some time...here's why:
>>>>>>
>>>>>> Downloading and installing the NDK/SDK won't be too hard...I have to
>>>>>> clear some space...but my primary machine is running Windows 7 and I'd
>>>>>> rather swallow hot coals than install Cygwin.  I've got next to no
>>>>>> experience with it, other than knowing that the NDK recommends against
>>>>>> it.
>>>>>>
>>>>>> I've got a CentOS VM...but it's currently in tarball form on an
>>>>>> external drive for space reasons...and it only has the NDK installed.
>>>>>> If I am able to get it back up and running, there's still the task of
>>>>>> getting  adb connected to my device. from the VM.
>>>>>>
>>>>>> Not saying it's impossible...just that it'll take time...and I'll
>>>>>> probably have to tackle it tomorrow (earliest) or Sunday (latest).  In
>>>>>> the meantime I'll also check to see if there's anything that can a)
>>>>>> run in an Android terminal and b) can take a stack trace; it would be
>>>>>> far, far, far easier than either option above.
>>>>>>
>>>>>>
>>>>>>
>>>>>> On Fri, Jan 30, 2015 at 4:19 PM, Ryan Gonzalez 
>>>>>> wrote:
>>>>>> > Do you have the Android SDK and NDK installed? If so...
>>>>>> >
>>>>>> > Using Google, I've created this series of steps, which may (or may
>>>>>> not)
>>>>>> > work:
>>>>>> >
>>>>>> > 1. Make sure you have a copy of Python on your computer and make
>>>>>> sure that
>>>>>> > it's built with debug symbols.
>>>>>> >
>>>>>> > 2. Run the following commands from a shell with your phone plugged
>>>>>> in:
>>>>>> >
>>>>>> >   adb forward tcp:5039 tcp:5039
>>>>>> >   adb shell /system/bin/gdbserver tcp:5039 >>>>> executable>
>>>>>> >   /arm-linux-androideabi-gdb
>>>>>> >
>>>>>> > Now, GDB should have opened, so type the following commands:
>>>>>> >
>>>>>> >   set solib-search-path 
>>>>>> >   file 
>>>>>> >   target remote :5055
>>>>>> >   run
>>>>>> >
>>>>>> > Now, wait for the program to crash and type:
>>>>>> >
>>>>>> >   backtrace
>>>>>> >
>>>>>> > You should now see a com

Re: [Python-Dev] Import Fails in setup.py On Android

[Ryan Gonzalez]

In reality, things just got broken even more. I don't know when that patch
was created, but it's now very out of date: importlib._bootstrap has no
load function. That's what the error you're getting is telling you. Since
it isn't getting to load anything, the issue seems "solved". Not really.

What's the full traceback for the undefined reference exception?

On Mon, Feb 2, 2015 at 2:04 PM, Cyd Haselton  wrote:

> Update: While waiting for replies I made the change referenced here:
> https://bugs.python.org/review/5309/diff2/12811:12826/setup.py?context=3&column_width=80
>
> specifically changing
> importlib. _bootstrap._SpecMethods(spec).load()
> to
> importlib._bootstrap.load(spec)
>
> I no longer get a terminating 'undefined reference to dlopen' error, but I
> do get 'importing extensions failed' errors for each extension...like this:
>
> *** WARNING: importing extension "_pickle" failed with  'AttributeError'>: 'module' object has no attribute 'load'
>
>
> On February 2, 2015 1:36:29 PM CST, Cyd Haselton 
> wrote:
>>
>> After fixing a segfault issue (many thanks Ryan) I'm back to the same
>> issue I was having with Python 2.7.8; the newly built python throws an
>> undefined reference to dlopen when running setup.py...specifically when
>> importing just-built extensions
>>
>> I've managed to narrow the problem down to the following line:
>>
>> importlib._bootstrap._SpecMethods(spec).load()
>>
>> Googling this brings up a few hits from bugs.python.org and not much
>> else. I'm new to Python; any ideas what this does...or where I can read up
>> on it for troubleshooting purposes?
>>
>
> --
> Sent from my Android device with K-9 Mail. Please excuse my brevity.
>
> ___
> 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/rymg19%40gmail.com
>
>


-- 
Ryan
If anybody ever asks me why I prefer C++ to C, my answer will be simple:
"It's becauseslejfp23(@#Q*(E*EIdc-SEGFAULT. Wait, I don't think that was
nul-terminated."
Personal reality distortion fields are immune to contradictory evidence. -
srean
Check out my website: http://kirbyfan64.github.io/
___
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] Import Fails in setup.py On Android

[Ryan Gonzalez]

Unfortunately, I have no idea. You might want to ask someone who's more
familiar with the Python source than I am.

What exactly appears? Does it say anything about the source of the error?

On Mon, Feb 2, 2015 at 3:24 PM, Cyd Haselton  wrote:

> No traceback unfortunately...the fakechroot in the environment throws the
> error and setup.py fails.
>
> I'll roll back that change...any idea where I could find info about the
> original method?
>
>
> On February 2, 2015 3:17:54 PM CST, Ryan Gonzalez 
> wrote:
>>
>> In reality, things just got broken even more. I don't know when that
>> patch was created, but it's now very out of date: importlib._bootstrap has
>> no load function. That's what the error you're getting is telling you.
>> Since it isn't getting to load anything, the issue seems "solved". Not
>> really.
>>
>> What's the full traceback for the undefined reference exception?
>>
>> On Mon, Feb 2, 2015 at 2:04 PM, Cyd Haselton  wrote:
>>
>>> Update: While waiting for replies I made the change referenced here:
>>> https://bugs.python.org/review/5309/diff2/12811:12826/setup.py?context=3&column_width=80
>>>
>>> specifically changing
>>> importlib. _bootstrap._SpecMethods(spec).load()
>>> to
>>> importlib._bootstrap.load(spec)
>>>
>>> I no longer get a terminating 'undefined reference to dlopen' error, but
>>> I do get 'importing extensions failed' errors for each extension...like
>>> this:
>>>
>>> *** WARNING: importing extension "_pickle" failed with >> 'AttributeError'>: 'module' object has no attribute 'load'
>>>
>>>
>>> On February 2, 2015 1:36:29 PM CST, Cyd Haselton 
>>> wrote:
>>>>
>>>> After fixing a segfault issue (many thanks Ryan) I'm back to the same
>>>> issue I was having with Python 2.7.8; the newly built python throws an
>>>> undefined reference to dlopen when running setup.py...specifically
>>>> when importing just-built extensions
>>>>
>>>> I've managed to narrow the problem down to the following line:
>>>>
>>>> importlib._bootstrap._SpecMethods(spec).load()
>>>>
>>>> Googling this brings up a few hits from bugs.python.org and not much
>>>> else. I'm new to Python; any ideas what this does...or where I can read up
>>>> on it for troubleshooting purposes?
>>>>
>>>
>>> --
>>> Sent from my Android device with K-9 Mail. Please excuse my brevity.
>>>
>>> ___
>>> 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/rymg19%40gmail.com
>>>
>>>
>>
>>
>> --
>> Ryan
>> If anybody ever asks me why I prefer C++ to C, my answer will be simple:
>> "It's becauseslejfp23(@#Q*(E*EIdc-SEGFAULT. Wait, I don't think that was
>> nul-terminated."
>> Personal reality distortion fields are immune to contradictory evidence.
>> - srean
>> Check out my website: http://kirbyfan64.github.io/
>>
>
> --
> Sent from my Android device with K-9 Mail. Please excuse my brevity.
>



-- 
Ryan
If anybody ever asks me why I prefer C++ to C, my answer will be simple:
"It's becauseslejfp23(@#Q*(E*EIdc-SEGFAULT. Wait, I don't think that was
nul-terminated."
Personal reality distortion fields are immune to contradictory evidence. -
srean
Check out my website: http://kirbyfan64.github.io/
___
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] ?s re documentation of Python features

[Ryan Gonzalez]

Ask on python-list .
Also check out the FAQ  and the Help
page . Not sure what your problem is;
Python is EXTREMELY well documented.

On Tue, Feb 24, 2015 at 7:15 PM, GARRY M CRANE  wrote:

> I am trying to learn Python for use in computational biology.  I am using
> the interesting book: "*Computing for Biologists; Python Programming and
> Principles*" (by Ran Libeskind-Hadas and Eliot Bush).  It has an
> interesting and useful set of programming exercises at www.cs.hmc.edu/CFB.
> I am actually enjoying solving (doing) the example problems.  However, I
> find some of the instructions non-functional for me.  For example the *import
> *function does not work,  nor *f=open("filename.txt")*.  I have saved
> files per instructions in the programming exercise inside the Python34
> folder (I am using Python 3.4 in Windows 7).  But use of the *f=open()*
> command produces an error message that the requested file does not exist. I
> assume I have chosen a wrong location for the saved file within that
> Python34 folder, but trial and error has not led to a successful use of
> these functions.  *import* simply leaves a blank line .. no suggestion
> about the problem.
>
> Asking questions in Google and Ask about  where to save Python-related
> files that can be used subsequently have not led to answers - just details
> about structuring or formatting things to be written/saved/use of the \n at
> end of each line, etc.  Important details, but of no help.   I am finding
> Python to be very handy at many biologic things such as working with DNA
> strings, etc. but I find the documentation and indexing for finding how to
> use many Python features exasperating.  I am writing to you based on a READ
> ME file in my Python folder - generated when I installed Python.
>
> FYI, I asked a few questions of one of the authors of the interesting book
> - who politely replied he was too busy to answer right now - the book and
> problems were meant for a class ... though neither the book nor problems
> say so.  The professor hopes to get around to issues of use by non-students
> sometime - but not now.
>
> Another feature I have come across so far that does not work is
> importation of *matplotlib*.  I copy computed results (that otherwise
> would go to your plotting routine)  then go to Excel and with manipulation
> produce a usable chart there - but at a cost of time and energy.
>
> Your Python tool has many intriguing features - but some of the most
> basic functions do not work for me (even though many features do, e.g.,
> import random does work).  The failure of these features - so far as I can
> tell - is  because of lack of description (for the general non-expert
> public) about where/how to install various features.  Perhaps I need to
> reinstall from the ground up???  If so, just what should I do?  If there is
> a less drastic solution, can you tell me about it?
>
> Thank you for any help ... and if you could provide me a lead regarding
> WHERE to ask subsequent questions I would be most grateful.  Sometimes,
> Google or Ask or a U Tube tutorial does a good job - but if one does not
> know the 'proper' name or term for something, it often is frustrating or
> impossible to get an answer.  I have not heard about any comprehensive
> handbook for Python34 aimed at one who wants to use Python for creating
> programs (functions) that work - and is not an expert at back-room
> structure of files and folders have I simply missed it?  So far, I have
> not found a local Python expert to ask for help.  I am sure some are in the
> greater Seattle area where I live- but I don't know how to find even one at
> this time.
>
> Garry Crane
> gandkcr...@msn.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/rymg19%40gmail.com
>
>


-- 
Ryan
If anybody ever asks me why I prefer C++ to C, my answer will be simple:
"It's becauseslejfp23(@#Q*(E*EIdc-SEGFAULT. Wait, I don't think that was
nul-terminated."
Personal reality distortion fields are immune to contradictory evidence. -
srean
Check out my website: http://kirbyfan64.github.io/
___
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] Working on issue 23496: should I use a macro test or an edit to configure.ac?

[Ryan Gonzalez]

So...

There was a recent discussion here on porting Python to Android. Well, for
those of you who saw too many unread messages and marked the whole thread
as read like I usually do, I helped Cyd figure out some patches that make
it work. Cyd then opened Issue 23496 .
Now, I'm going to try to redo the patches against HEAD (or tip in Mercurial
language).

Which leads me to the question. See, of course, the patches should only be
enabled if Python is being built targeting Android, but I'm not sure how
that should be detected.

I know that the Android target triple is arm-linux-androideabi. Should I
test for the __ANDROID__ macro in the source file, or should I modify
configure.ac to detect Android and define its own macro? Also, if a
configure.ac edit is preferred, where should it be? It's slightly painful
to scan through all 4000 lines of Python's configure script. ;)

-- 
Ryan
If anybody ever asks me why I prefer C++ to C, my answer will be simple:
"It's becauseslejfp23(@#Q*(E*EIdc-SEGFAULT. Wait, I don't think that was
nul-terminated."
Personal reality distortion fields are immune to contradictory evidence. -
srean
Check out my website: http://kirbyfan64.github.io/
___
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] Working on issue 23496: should I use a macro test or an edit to configure.ac?

[Ryan Gonzalez]

DOES NOBODY HAVE AN ANSWER TO THIS???

I'm REALLY relying on someone who works on Python to answer this. PLEASE??

On Wed, Feb 25, 2015 at 12:17 PM, Ryan Gonzalez  wrote:

> So...
>
> There was a recent discussion here on porting Python to Android. Well, for
> those of you who saw too many unread messages and marked the whole thread
> as read like I usually do, I helped Cyd figure out some patches that make
> it work. Cyd then opened Issue 23496 <http://bugs.python.org/issue23496>.
> Now, I'm going to try to redo the patches against HEAD (or tip in Mercurial
> language).
>
> Which leads me to the question. See, of course, the patches should only be
> enabled if Python is being built targeting Android, but I'm not sure how
> that should be detected.
>
> I know that the Android target triple is arm-linux-androideabi. Should I
> test for the __ANDROID__ macro in the source file, or should I modify
> configure.ac to detect Android and define its own macro? Also, if a
> configure.ac edit is preferred, where should it be? It's slightly painful
> to scan through all 4000 lines of Python's configure script. ;)
>
> --
> Ryan
> If anybody ever asks me why I prefer C++ to C, my answer will be simple:
> "It's becauseslejfp23(@#Q*(E*EIdc-SEGFAULT. Wait, I don't think that was
> nul-terminated."
> Personal reality distortion fields are immune to contradictory evidence. -
> srean
> Check out my website: http://kirbyfan64.github.io/
>



-- 
Ryan
If anybody ever asks me why I prefer C++ to C, my answer will be simple:
"It's becauseslejfp23(@#Q*(E*EIdc-SEGFAULT. Wait, I don't think that was
nul-terminated."
Personal reality distortion fields are immune to contradictory evidence. -
srean
Check out my website: http://kirbyfan64.github.io/
___
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] importante!!

[Ryan Gonzalez]

I think this was meant for python-list.

On Tue, Mar 31, 2015 at 10:13 AM, Alan Armour  wrote:

> its french! lol
>
> I just wanted to see if you could, as well as making python able to have
> assembly written, you should totally use blender as your main IDE it would
> be so epic
>
> and do pyjackd, and i think pyaudio will write some stuff, and like
> pycoreaudio and like directpy for windows direct x
>
> oh having blender as the main ide would just be epic
>
> ___
> 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/rymg19%40gmail.com
>
>


-- 
Ryan
[ERROR]: Your autotools build scripts are 200 lines longer than your
program. Something’s wrong.
http://kirbyfan64.github.io/
___
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] Type hints -- a mediocre programmer's reaction

[Ryan Gonzalez]

Only if you want Java users burning all written copies of the PEP...

On Mon, Apr 20, 2015 at 2:37 PM, Isaac Morland 
wrote:

> On Mon, 20 Apr 2015, Paul Moore wrote:
>
>  On 20 April 2015 at 19:41, Barry Warsaw  wrote:
>>
>>> tldr; type hints in python source are scary. Would reserving them for
 stub
 files be better?

>>>
>>> I think so.  I think PEP 8 should require stub files for stdlib modules
>>> and
>>> strongly encourage them for 3rd party code.
>>>
>>
>> Agreed. I have many of the same concerns as Harry, but I wouldn't have
>> expressed them quite as well. I'm not too worried about actually
>> removing annotations from the core language, but I agree that we
>> should create a strong culture of "type hints go in stub files" to
>> keep source files readable and clean.
>>
>> On that note, I'm not sure "stub" files is a particularly good name.
>> Maybe "type files" would be better? Something that emphasises that
>> they are the correct place to put type hints, not a workaround.
>>
>
> How about "header" files?
>
> (ducks...)
>
> Isaac Morland   CSCF Web Guru
> DC 2619, x36650 WWW Software Specialist
>
> ___
> 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/rymg19%40gmail.com
>



-- 
Ryan
[ERROR]: Your autotools build scripts are 200 lines longer than your
program. Something’s wrong.
http://kirbyfan64.github.io/
___
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] Type hints -- a mediocre programmer's reaction

[Ryan Gonzalez]

Although I like the concept of type annotations and the PEP, I have to
agree with this. If I saw these type annotations when learning Python (I'm
self-taught), there's a 99% chance I would've freaked.

It's the same issue as with teaching C++: it's wrong to say, "Hey, I taught
you the basics, but there's other stuff that's going to confuse you to a
ridiculous extent when you read it." People can't ignore it. It'll become a
normal part of Python programs.

At least now you can say, "I'm using the mypy type checker."

Don't get me wrong; I like mypy. I helped with their documentation and am
watching the GitHub repo. But this is dead-on.


On Mon, Apr 20, 2015 at 6:41 PM, Jack Diederich  wrote:

> Twelve years ago a wise man said to me "I suggest that you also propose a
> new name for the resulting language"
>
> I talked with many of you at PyCon about the costs of PEP 484. There are
> plenty of people who have done a fine job promoting the benefits.
>
> * It is not optional. Please stop saying that. The people promoting it
> would prefer that everyone use it. If it is approved it will be optional in
> the way that PEP8 is optional. If I'm reading your annotated code it is
> certainly /not/ optional that I understand the annotations.
>
> * Uploading stubs for other people's code is a terrible idea. Who do I
> contact when I update the interface to my library? The random Joe who
> "helped" by uploading annotations three months ago and then quit the
> internet? I don't even want to think about people maliciously adding stubs
> to PyPI.
>
> * The cognitive load is very high. The average function signature will
> double in length. This is not a small cost and telling me it is "optional"
> to pretend that every other word on the line doesn't exist is a farce.
>
> * Every company's style guide is about to get much longer. That in itself
> is an indicator that this is a MAJOR language change and not just some
> "optional" add-on.
>
> * People will screw it up. The same people who can't be trusted to program
> without type annotations are also going to be *writing* those type
> annotations.
>
> * Teaching python is about to get much less attractive. It will not be
> optional for teachers to say "just pretend all this stuff over here doesn't
> exist"
>
> * "No new syntax" is a lie. Or rather a red herring. There are lots of new
> things it will be required to know and just because the compiler doesn't
> have to change doesn't mean the language isn't undergoing a major change.
>
> If this wasn't in a PEP and it wasn't going to ship in the stdlib very few
> people would use it. If you told everyone they had to install a different
> python implementation they wouldn't. This is much worse than that - it is
> Python4 hidden away inside a PEP.
>
> There are many fine languages that have sophisticated type systems. And
> many bondage & discipline languages that make you type things three times
> to make really really sure you meant to type that. If you find those other
> languages appealing I invite you to go use them instead.
>
> -Jack
>
> https://mail.python.org/pipermail/python-dev/2003-February/033291.html
>
> ___
> Python-Dev mailing list
> Python-Dev@python.org
> https://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe:
> https://mail.python.org/mailman/options/python-dev/rymg19%40gmail.com
>
>


-- 
Ryan
[ERROR]: Your autotools build scripts are 200 lines longer than your
program. Something’s wrong.
http://kirbyfan64.github.io/
___
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 3152 and yield from Future()

[Ryan Gonzalez]

Then blow it up like Duck Dynasty does.

On April 23, 2015 12:07:46 PM CDT, Antoine Pitrou  wrote:
>On Thu, 23 Apr 2015 09:58:33 -0700
>Guido van Rossum  wrote:
>> I think this is the nail in PEP 3152's coffin.
>
>If you only put one nail, it might manage to get out.
>
>Regards
>
>Antoine.
>
>
>___
>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/rymg19%40gmail.com

-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.___
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] Sub-claasing pathlib.Path seems impossible

[Ryan Gonzalez]

http://stackoverflow.com/a/29880095/2097780

My favorite thing about Python is that it's so easy to be evil. ;)


On Fri, May 1, 2015 at 2:30 PM, Christophe Bal  wrote:

> Hello.
>
> In this post
> ,
> I have noticed a problem with the following code.
>
> from pathlib import Path
>> class PPath(Path):
>> def __init__(self, *args, **kwargs):
>> super().__init__(*args, **kwargs)
>>
>> test = PPath("dir", "test.txt")
>>
>>
> This gives the following error message.
>
>
>
>> Traceback (most recent call last):
>>   File "/Users/projetmbc/test.py", line 14, in 
>> test = PPath("dir", "test.txt")
>>   File "/anaconda/lib/python3.4/pathlib.py", line 907, in __new__
>> self = cls._from_parts(args, init=False)
>>   File "/anaconda/lib/python3.4/pathlib.py", line 589, in _from_parts
>> drv, root, parts = self._parse_args(args)
>>   File "/anaconda/lib/python3.4/pathlib.py", line 582, in _parse_args
>> return cls._flavour.parse_parts(parts)AttributeError: type object 
>> 'PPath' has no attribute '_flavour'
>>
>>
> This breaks the sub-classing from Python point of view. In the post
> ,
> I give a hack to sub-class Path but it's a bit Unpythonic.
>
> *Christophe BAL*
> *Enseignant de mathématiques en Lycée **et développeur Python amateur*
> *---*
> *French math teacher in a "Lycée" **and **Python **amateur developer*
>
> ___
> 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/rymg19%40gmail.com
>
>


-- 
Ryan
[ERROR]: Your autotools build scripts are 200 lines longer than your
program. Something’s wrong.
http://kirbyfan64.github.io/
___
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] Interesting what version of python should I start with

[Ryan Gonzalez]

This list is for development of Python itself, not development with
Python. You want python-list:
https://mail.python.org/mailman/listinfo/python-list

That being said: use the latest version (3.6 as of right now).

On Thu, Nov 2, 2017 at 12:52 PM, Bob Woolsey  wrote:
>
>
> Sent from my iPhone
> ___
> 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/rymg19%40gmail.com



-- 
Ryan (ライアン)
Yoko Shimomura, ryo (supercell/EGOIST), Hiroyuki Sawano >> everyone else
https://refi64.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] Removing files from the repository

[Ryan Gonzalez]

Doesn't Git make this rather easy, though?

e.g. you can find all deleted files with:

git log --diff-filter=D --summary

and find a specific file with (showing glob patterns):

git log --all --full-history -- **/thefile.*

and then show it:

git show  -- 

or restore it:

git checkout ^ -- 

https://stackoverflow.com/questions/7203515/git-how-to-search-for-a-deleted-file-in-the-project-commit-history

On Wednesday, November 29, 2017 12:26:01 PM CST, Serhiy Storchaka wrote:
After removing files from the repository they disappear from 
the source tree, and it is even hard to notice this if you don't 
use it regularly. It is hard to track the history of the removed 
file even if you know it exact path. If you know it only 
approximate this is harder.


I think that any file removals from the repository should pass 
some PEP-like process. Declaring the intention with the 
rationale, taking a feedback, discussing, and finally 
documenting the removal. Perhaps it is worth to track all 
removals in a special file, so if later you will find that the 
removed file can be useful you could restore it instead of 
recreating its functionality from zero in the case if you even 
don't know that similar file existed.




--
Ryan (ライアン)
Yoko Shimomura, ryo (supercell/EGOIST), Hiroyuki Sawano >> everyone else
https://refi64.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] Mostly Official Python Development Container Image

[Ryan Gonzalez]

Question: why is this using GitLab while CPython itself is using GitHub + 
Travis?

On December 10, 2017 6:13:53 PM CST, Barry Warsaw  wrote:
>As part of our work on importlib_resources, and with some fantastic
>help from Abhilash Raj, we now have a mostly official Python
>development container image that you can use for CI testing and other
>development purposes.
>
>This image is based on Ubuntu 16.04 LTS and provides the latest stable
>releases of Python 2.7, and 3.4-3.6, along with a mostly up-to-date git
>checkout of master, currently Python 3.7 of course.  Once 3.7 is
>released to beta, we intend to track its release tarballs too.  Note
>that these are pristine builds of upstream releases, so they don’t have
>any of the Ubuntu or Debian platform changes.
>
>We also install a few other commonly needed tools, like pip, git,
>unzip, wget, mypy, and tox.
>
>We do *not* recommend this image for application deployment purposes;
>use this for development and testing only, please.
>
>Here’s the project repo:
>
>https://gitlab.com/python-devs/ci-images
>
>We’re publishing this image automatically to quay.io, so you can pull
>the image in a .gitlab-ci.yml file to run tests against all these
>versions of Python.  Here’s an example from the importlib_resources
>project:
>
>https://gitlab.com/python-devs/importlib_resources/blob/master/.gitlab-ci.yml
>
>We welcome contributors on the ci-images GitLab project!
>
>Cheers,
>-Barry

--
Ryan (ライアン)
Yoko Shimomura, ryo (supercell/EGOIST), Hiroyuki Sawano >> everyone else
https://refi64.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] Trying to build from source, test-poplib fails

[Ryan Gonzalez]

Do you have ca-certificates installed?

On April 7, 2018 5:33:35 PM Skip Montanaro  wrote:


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/rymg19%40gmail.com


--
Ryan (ライアン)
Yoko Shimomura, ryo (supercell/EGOIST), Hiroyuki Sawano >> everyone else
https://refi64.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

[Python-Dev] Is PEP 572 really the most effective way to solve the problems it's targeting?

[Ryan Gonzalez]

I have to say I'm not overly thrilled with PEP 572...it's almost odd, 
because if you asked me back when I first joined this list when I was 13, I 
would've no doubt said *YES*. But, since then, I've gone across many 
projects and languages, and fundamentally *I have never felt hurt by the 
lack of assignment in an expression*, and I always regretted every time I 
tried it in C or Crystal. I understand this experience is pretty 
insignificant in comparison to many of the wizards here, but I thought I'd 
still share it as an opener for what I'm about to say.




With this being said, I'd encourage everyone to take a bit of a step back: 
what exactly are people looking for in PEP 572?


I see two main goals:

- Assignment in a conditional structure.
- Assignment in a list comprehension.

Most other use cases would significantly hurt readability and seem pretty rare.

Now let's break down the top one:

- Assignment in an if condition.
- Assignment in a while condition.

So there are roughly three main goals here overall. Now, are there better 
ways to solve these?


(FWIW C solved the while condition one with the C-style for loop, but I'm 
pretty sure few people here would really go for that.)


C++ has recently solved the if condition by allowing declarations inside 
the conditions:


if (auto a = 123; a != 456) {

Many languages have a 'let' expression (using Felix as my example):

if let a = 1, b = 2 in a == b then

Swift has taken a bit of a hybrid between the above two:

if let a = 1, b = 2, a == b {

Now, what's the common theme here? **Declarations should be separate from 
expressions.** We've got languages that range from baggage-filled to 
functional to a bit of all of the above, and none of them have added 
assignment *inside* an expression.


The argument is roughly the same across all boards: you're putting major 
but easy-to-miss side effects in the midst of expressions that *seem* pure.


All this is to say: I'd really encourage everyone here to think a bit more 
about *why* exactly you want this feature, and then think if there's really 
no better way. Any solution that separates declarations would be far more 
readable, (arguably) more Pythonic, and play more nicely with the new-ish 
typing features to boot


I understand reluctance to add a syntax exception like this, but I really 
feel it'd be worth it.


As a side note, I was a strong supporter of comprehension generalizations, 
f-strings, *and* dataclasses. However, this proposal seems a bit ugly and 
excessive for what it's trying to accomplish.


P.S. Yes, the unmatched curly braces were intentional to drive you crazy 
for a few hours. I blame Randall Monroe. You're welcome.


--
Ryan (ライアン)
Yoko Shimomura, ryo (supercell/EGOIST), Hiroyuki Sawano >> everyone else
https://refi64.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] Is PEP 572 really the most effective way to solve the problems it's targeting?

[Ryan Gonzalez]

On April 25, 2018 11:05:04 PM Steven D'Aprano  wrote:

On Wed, Apr 25, 2018 at 09:36:31PM -0500, Ryan Gonzalez wrote:


I have to say I'm not overly thrilled with PEP 572...it's almost odd,
because if you asked me back when I first joined this list when I was 13, I
would've no doubt said *YES*.

I have the opposite experience: I've warmed to it the more I have read
it. Before Chris had even written this PEP, there was a Python-Ideas
thread asking for dedicated syntax in comprehensions alone that would
have been equivalent to a binding-expression. I was rather negative
about the whole thing (but no where near as negative as I've been in
the past when this has come up before), until Chris pointed out that
such binding-expressions have value outside of comprehensions.


[...]
Now, what's the common theme here? **Declarations should be separate from
expressions.**

Declarations and assignments are not the same thing.

Yeah, this is what happens when I write these things when tired... I meant 
to also mention assignments here, and anywhere else I may have used 
"declaration".




We've got languages that range from baggage-filled to
functional to a bit of all of the above, and none of them have added
assignment *inside* an expression.

And your claim about assignment inside expressions is only true if you
ignore the languages where assignment is an expression with a return
value. You know, strange and exotic languages with hardly any users or
influence, like C, C++, C#, Java, Javascript, Ruby, Perl, PHP, Lisp ...

In the majority of these, however, mixing assignments into expressions is 
considered bad practice.


For instance:

- C++ core guidelines: 
https://github.com/isocpp/CppCoreGuidelines/blob/master/CppCoreGuidelines.md#Res-complicated
- MediaWiki style guide: 
https://m.mediawiki.org/wiki/Manual:Coding_conventions/PHP


Some of the other languages (e.g. Perl) aren't some I'd regard as positive 
influences...




--
Steve
___
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/rymg19%40gmail.com


--
Ryan (ライアン)
Yoko Shimomura, ryo (supercell/EGOIST), Hiroyuki Sawano >> everyone else
https://refi64.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] Is PEP 572 really the most effective way to solve the problems it's targeting?

[Ryan Gonzalez]

On April 27, 2018 12:16:09 AM Mike Miller  wrote:

Sorry all, wasn't specific enough.

By "modern" I mean the last decade perhaps.  New languages that have had a
chance to look at the older generations and choose their best ideas, while
leaving behind the rest.

Personally I thought of Swift (Ryan mentioned), Kotlin, Rust, and perhaps Go,
though Go wasn't focused on breaking new ground outside of ease of concurrency.
I don't know R or Felix at all, but sound interesting.  Nim is another I'm
vaguely aware of.  They surely have given some thought to the issue.

One thing that jumped out at me is that most replies here jumped to the 
question
of whether they supported assignment-expressions, but that is only one 
potential
solution.  To be more clear, I wondered how did they solve "the problem 
itself?"

Was their solution different?  Ryan somewhat alluded to that, but I'd like to
dig in a bit on that part.

In contrast, in many of the other threads I heard, "C, C++, C#, Java, etc do
assignment-expressions, they're useful and not so hard to learn."  Ok that's
reasonable, but where is the industry headed?  Python deferred long enough that
we don't necessarily have to choose a classic solution.

So, it sounds like many of the new generation of languages are not embracing
these expressions everywhere but rather letting folks do an assignment right in
the statement where their use case applies, if, while, maybe 
comprehensions.  Is

that accurate?

This is basically what I was trying to say, except far better worded...


Looks like I've got some homework to do, haha.

-Mike


On 2018-04-26 17:58, Steven D'Aprano wrote:
What counts as a modern language? Less than five years old? Less than
fifty years old? Are Javascript, Ruby and R modern? They all support
assignment as expressions.

I think Koitlin, Rust and Go prohibit assignment as expressions.

Swift assignment evaluates as Void (equivalent to None in Python, I
guess), so you can use assignment in an expression but it returns
nothing and only operates by side-effect.

As far as type hints go, I think that if you need explicit type hints in
the middle of an expression, it's a bad idea and you ought to pull it
out as a separate statement. That applies regardless of whether that
expression involves binding or not.
___
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/rymg19%40gmail.com


--
Ryan (ライアン)
Yoko Shimomura, ryo (supercell/EGOIST), Hiroyuki Sawano >> everyone else
https://refi64.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] Python startup time

[Ryan Gonzalez]

I'm hardly an expert, but AFAIK CPython's start-up issues are more due to a 
mix of architectural issues and the fact that it's hard to optimize imports 
while maintaining backwards compatibility with Python's dynamism.


--
Ryan (ライアン)
Yoko Shimomura, ryo (supercell/EGOIST), Hiroyuki Sawano >> everyone else
https://refi64.com/



On May 3, 2018 1:37:57 AM Glenn Linderman  wrote:


On 5/2/2018 8:56 PM, Gregory Szorc wrote:

Nobody in the project is seriously talking about a complete rewrite in
Rust. Contributors to the project have varying opinions on how
aggressively Rust should be utilized. People who contribute to the C
code, low-level primitives (like storage, deltas, etc), and those who
care about performance tend to want more Rust. One thing we almost
universally agree on is that we want to rewrite all of Mercurial's C
code in Rust. I anticipate that figuring out the balance between Rust
and Python in Mercurial will be an ongoing conversation/process for
the next few years.

Have you considered simply rewriting CPython in Rust?

And yes, the 4th word in that question was intended to produce peals of
shocked laughter. But why Rust? Why not Go? http://esr.ibiblio.org/?p=7724



--
___
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/rymg19%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/archive%40mail-archive.com

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

[Ryan Gonzalez]

On May 3, 2018 11:56:24 AM MRAB  wrote:


On 2018-05-03 13:24, Steve Holden wrote:

On Thu, May 3, 2018 at 12:12 AM, Ivan Pozdeev via Python-Dev
mailto:python-dev@python.org>> wrote:

On 03.05.2018 1:01, Antoine Pitrou wrote:

On Wed, 2 May 2018 22:54:04 +0100
Paul Moore mailto:p.f.mo...@gmail.com>> wrote:

On 2 May 2018 at 22:37, Antoine Pitrou mailto:solip...@pitrou.net>> wrote:

To elaborate a bit: the OP, while angry, produced both a
detailed
analysis *and* a PR.  It's normal to be angry when an
advertised
feature doesn't work and it makes you lose hours of work
(or, even,
forces you to a wholesale redesign). Producing a
detailed analysis and a
PR is more than most people will ever do.

His *other* email seems reasonable, and warrants a response,
yes. But
are we to take the suggestion made here (to drop tkinter)
seriously,
based on the fact that there's a (rare - at least it appears
that the
many IDLE users haven't hit it yet) race condition that
causes a crash
in Python 2.7? (It appears that the problem doesn't happen
in the
python.org  3.x builds, if I understand
the description of the issue).

In 3.x, Tkinter+threads is broken too, albeit in a different way --
see https://bugs.python.org/issue33412
 (this should've been the 2nd
link in the initial message, sorry for the mix-up).


​The observation in t​hat issue that tkinter and threads should be
handled in specific ways is certainly a given for old hands, who have
long put the GUI code in one thread with one or more concurrent worker
threads typically communicating through queues. But I haven't built
anything like that recently, so I couldn't say how helpful the current
documenation might be.


Interacting with the GUI only in the main thread is something that I've
had to do in other languages (it is/was the recommended practice), so I
naturally do the same with Python and tkinter. It's also easier to
reason about because you don't get elements of the GUI changing
unexpectedly.


To add to this, most GUI frameworks disallow modifications outside the main 
thread altogether. IIRC both GTK+ and Qt require this, or else it's 
undefined altogether.




[snip]
___
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/rymg19%40gmail.com



--
Ryan (ライアン)
Yoko Shimomura, ryo (supercell/EGOIST), Hiroyuki Sawano >> everyone else
https://refi64.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] Slow down...

[Ryan Gonzalez]

10 years feels like a simultaneously long and arbitrary limit. IMO a policy
of "try to avoid major language features for a while" would work better.

On Mon, May 7, 2018 at 2:11 PM Craig Rodrigues 
wrote:

>
>
> On Sun, May 6, 2018 at 7:35 PM Nick Coghlan  wrote:
>
>>
>> I'm inclined to agree that a Python 3.8 PEP in the spirit of the PEP 3003
>> language moratorium could be a very good idea. Between matrix
>> multiplication, enhanced tuple unpacking, native coroutines, f-strings, and
>> type hinting for variable assignments, we've had quite a bit of syntactic
>> churn in the past few releases, and the rest of the ecosystem really hasn't
>> caught up on it all yet (and that's not just other implementations - it's
>> training material, online courses, etc, etc).
>>
>> If we're going to take such a step, now's also the time to do it, since
>> 3.8 feature development is only just getting under way, and if we did
>> decide to repeat the language moratorium, we could co-announce it with the
>> Python 3.7 release.
>>
>>
> Would it be reasonable to request a 10 year moratorium on making changes
> to the core Python language,
> and for the next 10 years only focus on things that do not require core
> language changes,
> such as improving/bugfixing existing libraries, writing new libraries,
> improving tooling, improving infrastructure (PyPI),
> improving performance, etc., etc.?
>
> There are still many companies still stuck on Python 2, so giving 10 years
> of breathing room
> for these companies to catch up to Python 3 core language, even past 2020
> would be very helpful.
>
> --
> Craig
> ___
> 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/rymg19%40gmail.com
>


-- 
Ryan (ライアン)
Yoko Shimomura, ryo (supercell/EGOIST), Hiroyuki Sawano >> everyone else
https://refi64.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] A fast startup patch (was: Python startup time)

[Ryan Gonzalez]

On May 7, 2018 9:15:32 PM Steve Dower  wrote:

“the data shows that a focused change to address file system inefficiencies 
has the potential to broadly and transparently deliver benefit to users 
without affecting existing code or workflows.”


This is consistent with a Node.js experiment I heard about where they 
compiled an entire application in a single (HUGE!) .js file. Reading a 
single large file from disk is quicker than many small files on every 
significant file system I’m aware of. Is there benefit to supporting import 
of .tar files as we currently do .zip? Or perhaps having a special 
fast-path for uncompressed .zip files?


I kind of built something like this, though I haven't really put in the 
effort to make it overly usable yet:


https://github.com/kirbyfan64/bluesnow

(Bonus points to anyone who gets the character reference in the name, 
though I seriously doubt it.)


Main thing I noticed was that reading compiled .pyc files is far faster 
than uncompiled Python code, even if you eliminate the disk access. Kind of 
obvious in retrospect, but still something to note


However, there are more obstacles to this in the Python world than the JS 
world. C extensions have a heavier prevalence here, distribution is a bit 
weirder (sorry, even with Pipfiles), and JavaScript already has an entire 
ecosystem built around packing files together from the web world.




Top-posted from my Windows phone

From: Carl Shapiro
Sent: Monday, May 7, 2018 14:36
To: Nathaniel Smith
Cc: Nick Coghlan; Python Dev
Subject: Re: [Python-Dev] A fast startup patch (was: Python startup time)

On Fri, May 4, 2018 at 6:58 PM, Nathaniel Smith  wrote:
What are the obstacles to including "preloaded" objects in regular .pyc 
files, so that everyone can take advantage of this without rebuilding the 
interpreter?


The system we have developed can create a shared object file for each 
compiled Python file.  However, such a representation is not directly 
usable.  First, certain shared constants, such as interned strings, must be 
kept globally unique across object code files.  Second, some marshaled 
objects, such as the hashed collections, must be initialized with 
randomization state that is not available until after the hosting runtime 
has been initialized.


We are able to work around the first issue by generating a heap image with 
the transitive closure of all modules that will be loaded which allows us 
to easily maintain uniqueness guarantees.  We are able to work around the 
second issue with some unobservable changes to the affected data structures.

 
Based on our numbers, it appears there should be some hesitancy--at this 
time--to changing the format of compiled Python file for the sake of 
load-time performance.  In contrast, the data shows that a focused change 
to address file system inefficiencies has the potential to broadly and 
transparently deliver benefit to users without affecting existing code or 
workflows. 





--
___
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/rymg19%40gmail.com





--
Ryan (ライアン)
Yoko Shimomura, ryo (supercell/EGOIST), Hiroyuki Sawano >> everyone else
https://refi64.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] Python startup time

[Ryan Gonzalez]

 https://refi64.com/uprocd/ 


On May 11, 2018 9:39:28 AM Chris Barker - NOAA Federal via Python-Dev 
 wrote:



Inspired by chg:

Could one make a little startup utility that, when invoked the first
time, starts up a raw python interpreter, keeps it running somewhere,
and then forks it to run the actual python code.

Then every invocation after that would make a new fork. I presume
forking is a LOT faster than re-invoking the entire startup.

I suspect that many of the cases where startup time really matters is
when a command line utility is likely to be invoked many times — often
in the same shell instance.

So having a “pre-built” warm interpreter ready to go could really help.

This is way past my technical expertise to know if it’s possible, or
to try to prototype it, but I’m sure many of you would know.

-CHB

Sent from my iPhone


On May 7, 2018, at 12:28 PM, Neil Schemenauer  wrote:

On 2018-05-03, Lukasz Langa wrote:

On May 2, 2018, at 8:57 PM, INADA Naoki  wrote:
* Add lazy compiling API or flag in `re` module.  The pattern is compiled
when first used.


How about go the other way and allow compiling at Python
*compile*-time? That would actually make things faster instead of
just moving the time spent around.


Lisp has a special form 'eval-when'.  It can be used to cause
evaluation of the body expression at compile time.

In Carl's "A fast startup patch" post, he talks about getting rid of
the unmarshal step and storing objects in the heap segment of the
executable.  Those would be the objects necessary to evaluate code.
The marshal module has a limited number of types that it handle.
I believe they are: bool, bytes, code objects, complex, Ellipsis
float, frozenset, int, None, tuple and str.

If the same mechanism could handle more types, rather than storing
the code to be evaluated, we could store the objects created after
evaluation of the top-level module body.  Or, have a mechanism to
mark which code should be evaluated at compile time (much like the
eval-when form).

For the re.compile example, the compiled regex could be what is
stored after compiling the Python module (i.e. the re.compile gets
run at compile time).  The objects created by re.compile (e.g.
SRE_Pattern) would have to be something that the heap dumper could
handle.

Traditionally, Python has had the model "there is only runtime".
So, starting to do things at compile time complicates that model.

Regards,

 Neil
___
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/chris.barker%40noaa.gov

___
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/rymg19%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/archive%40mail-archive.com

Re: [Python-Dev] Troubles to merge changes in the 2.7 branch: PR "out-of-date" branch

[Ryan Gonzalez]

AFAIK there's no setting like this available, and I've done this many times 
on other repos with no trouble. Maybe it could be a GitHub bug?



On May 28, 2018 4:59:03 AM Victor Stinner  wrote:


Hi,

Since one or two weeks, I noticed that it's difficult to merge pull
requests into the 2.7 branch. If a different commit is pushed in the
meanwhile (if a different PR has been merged), the 2.7 branch diverges
and the PR is immediately marked as "This branch is out-of-date with
the base branch" and the "Squash and Merge" button is disabled (grey).

For example my PR https://github.com/python/cpython/pull/7120 which
changes Lib/test/regrtest.py cannot be merged because a commit
touching the documentation (Doc/ directory) has been merged after I
posted my PR and before the CI completed.

I don't see the same behavior on the master branch. Is the 2.7 branch
configured as more strict?

Victor
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/rymg19%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/archive%40mail-archive.com

Re: [Python-Dev] Unable to build regex module against Python 3.5 32-bit

[Ryan Gonzalez]

Try building the module with -m32. The error message basically means: 
"../libpython35.a is 32-bit, but what you're building is 64-bit." Gotta love ld!

On May 25, 2015 3:06:01 PM CDT, MRAB  wrote:
>As the subject says, I've been unable to build the regex module against
>Python 3.5b1 for 32-bit. MingGW says:
>
>  skipping incompatible .../libpython35.a when searching for -lpython35
>
>It builds without a problem against Python 3.5 for 64-bit.
>
>Any ideas? Should I just wait until beta 2?
>___
>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/rymg19%40gmail.com

-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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

[Ryan Gonzalez]

py2exe tends to invoke DLL hell if you have various versions of VS or Office or 
both installed. Because Windows.


On May 28, 2015 11:23:57 AM CDT, Chris Barker  wrote:
>I'm confused:
>
>Doesn't py2exe (optionally) create a single file executable?
>
>And py2app on the Mac creates an application bundle, but that is
>more-or-less the equivalent on OS-X (you may not even be able to have a
>single file executable that can access the Window Manager, for
>instance)
>
>Depending on what extra packages you need, py2exe's single file doesn't
>always work, but last I tried, it worked for a fair bit (I think all of
>the
>stdlib).
>
>I don't know what PyInstaller or others create. And I have no idea if
>there
>is a linux option -- but it seems like the standard of practice for an
>application for linux is a bunch of files scattered over the system
>anyway
>:-)
>
>Yes, the resulting exe is pretty big, but it does try to include only
>those
>modules and packages that are used, and that kind of optimization could
>be
>improved in any case.
>
>So is something different being asked for here?
>
>Barry Warsaw wrote:
>>> I do think single-file executables are an important piece to
>Python's long-term
>competitiveness.
>
>Really? It seems to me that desktop development is dying. What are the
>critical use-cases for a single file executable?
>
>And I'd note that getting a good way to use Python to develop for iOS,
>Android, and Mobile Windows is FAR more critical!  -- maybe that's the
>same
>problem ?
>
>-Chris
>
>
>On Thu, May 28, 2015 at 8:39 AM, Donald Stufft 
>wrote:
>
>>
>>
>> On May 28, 2015 at 11:30:37 AM, Steve Dower
>(steve.do...@microsoft.com)
>> wrote:
>> > Donald Stufft wrote:
>> > > Well Python 3.4.3 binary is 4kb for me, so you'd have that + your
>1KB
>> Python script + whatever
>> > other pieces you need.
>> >
>> > For contrast, here are the things you need on Windows to be able to
>get
>> to an interactive
>> > prompt (I don't know how other platforms get this down to 4KB...):
>> >
>> > * python.exe (or some equivalent launcher) 39KB
>> > * python35.dll 3,788KB
>> > * vcruntime140.dll 87KB (the rest of the CRT is about 1MB, but is
>not
>> redistributable
>> > so doesn't count here)
>> > * 26 files in Lib 343KB
>> >
>> > This gets you to ">>>", and basically everything after that is
>going to
>> fail for some reason.
>> > That's an unavoidable 4,257KB.
>> >
>> > The rest of the stdlib adds another ~16MB once you exclude the test
>> suite, so a fully functioning
>> > Python is not cheap. (Using compressed .pyc's in a zip file can
>make a
>> big difference here
>> > though, assuming you're willing to trade CPU for HDD.)
>> >
>> > Cheers,
>> > Steve
>> >
>> >
>>
>> You don’t need a "fully functioning Python" for a single file binary,
>you
>> only
>> need enough to actually run your application. For example, if you're
>making
>> an application that can download files over HTTP, you don't need to
>include
>> parts of the stdlib like xmlrpc, pickle, shelve, marshall, sqlite,
>csv,
>> email,
>> mailcap, mailbox, imaplib, nntplib, etc.
>>
>> Of course deciding which pieces you include in the zip file you're
>> appending
>> to the end of Python is up to whatever tool builds this executable
>which
>> doesn't need to be part of Python itself. If Python itself gained the
>> ability
>> to operate in that manner than third party tools could handle trying
>to do
>> the
>> optimizations where it only includes the things it actually needs in
>the
>> stdlib
>> and excludes things it doesn't. The key thing here is that since
>you're
>> doing
>> a single file binary, you don't need to have a Python which is
>suitable to
>> execute random Python code, you only need one that is suitable to
>execute
>> this
>> particular code so you can specialize what that includes.
>>
>> ---
>> Donald Stufft
>> PGP: 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA
>>
>>
>> ___
>> 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/chris.barker%40noaa.gov
>>
>
>
>
>-- 
>
>Christopher Barker, Ph.D.
>Oceanographer
>
>Emergency Response Division
>NOAA/NOS/OR&R(206) 526-6959   voice
>7600 Sand Point Way NE   (206) 526-6329   fax
>Seattle, WA  98115   (206) 526-6317   main reception
>
>chris.bar...@noaa.gov
>
>
>
>
>___
>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/rymg19%40gmail.com

-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailma

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

[Ryan Gonzalez]

I agree that size is an issue, but is it really that bad? Just compare it to 
the recent "web surge" where everyone is writing desktop apps in HTML5+CSS+JS 
and bundling a huge WebKit engine in their apps binary.

Python on Windows is seriously in a bad state. IMO, what needs to be 
prioritized is the ability to make exes that *actually work* with nicer GUI 
abilities. py2exe gives too many random DLL errors and PyInstaller is an ugly 
hack that just shoves 20 DLLs with your executable. Mixed with the fact that 
TkInter looks even uglier when built via py2exe and almost everything else 
(PyGI, PySide, etc.) requires yet another 20 DLLs (PySide threw in Qt DLLs that 
I didn't even use!), it's sad. Really sad.

This is most of the reason I write programs that I plan on distributing to 
various crowds in some statically compiled language (C++, Nim, Felix, not Go) 
with (when necessary) a statically-linked GUI library. Less DLL hell, less free 
files, etc.

Oh yeah, and add to that the problems with running both Python 2 and 3 on 
Windows while using some binaries that want 3 and others that want 2. It's 
painful.


On May 28, 2015 10:30:33 AM CDT, Steve Dower  wrote:
>Donald Stufft wrote:
>> Well Python 3.4.3 binary is 4kb for me, so you'd have that + your 1KB
>Python script + whatever other pieces you need.
>
>For contrast, here are the things you need on Windows to be able to get
>to an interactive prompt (I don't know how other platforms get this
>down to 4KB...):
>
>* python.exe (or some equivalent launcher) 39KB
>* python35.dll 3,788KB
>* vcruntime140.dll 87KB (the rest of the CRT is about 1MB, but is not
>redistributable so doesn't count here)
>* 26 files in Lib 343KB
>
>This gets you to ">>>", and basically everything after that is going to
>fail for some reason. That's an unavoidable 4,257KB.
>
>The rest of the stdlib adds another ~16MB once you exclude the test
>suite, so a fully functioning Python is not cheap. (Using compressed
>.pyc's in a zip file can make a big difference here though, assuming
>you're willing to trade CPU for HDD.)
>
>Cheers,
>Steve
> 
>___
>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/rymg19%40gmail.com

-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.___
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

[Ryan Gonzalez]

YESSS!!!

On Thu, May 28, 2015 at 8:09 PM, Larry Hastings  wrote:

>  On 05/28/2015 05:58 PM, Victor Stinner wrote:
>
> Why not continue to enhance Python 3 instead of wasting our time with
> Python 2? We have limited resources in term of developers to maintain
> Python.
>
>
> Uh, guys, you might as well call off the debate.  Benjamin already checked
> it in.
>
> https://hg.python.org/cpython/rev/17d3bbde60d2
>
>
> */arry*
>
> ___
> 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/rymg19%40gmail.com
>
>


-- 
Ryan
[ERROR]: Your autotools build scripts are 200 lines longer than your
program. Something’s wrong.
http://kirbyfan64.github.io/
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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

[Ryan Gonzalez]

I did that once; it wasn't worth it. It was no smaller than what
PyInstaller would output and required manually adding in the required
modules that weren't in the stdlib, along with any extra DLLs (e.g. the Qt
DLLs).


On Fri, May 29, 2015 at 4:45 PM, Paul Moore  wrote:

> On 29 May 2015 at 21:49, Glenn Linderman  wrote:
> >
> > That looks interesting, I wonder what compilation environment it would
> need?
> > I don't think I've even installed a C compiler on my last couple boxes,
> and
> > the only version of a C compiler I have is, umm... M$VC++6.0, since I've
> > moved to using Python for anything a 5 line batch file can't do...
> >
> >> One mildly annoying thing is that python3.dll is only installed in
> >> \DLLs, which typically isn't on PATH.
> >
> > Ah, linking so I guess if I figured out how to create this binary, it
> > would contain a reference to python3.dll that would attempt to be
> resolved
> > via the PATH, from what you say, and typically fail, due to PATH seldom
> > containing python3.dll.  The python launcher gets around that by (1)
> being
> > installed in %windir%, and going and finding the appropriate Python (per
> its
> > own configuration file, and command line parameters), and setting up the
> > path to that Python, which, when executed, knows its own directory
> structure
> > and can thus find its own python3.dll.
> >
> > The launcher, of course, adds an extra layer of process between the shell
> > and the program, because it launches the "real" Python executable.
> >
> >> So actually using the limited API from your own application fails by
> >> default.
> >> Fixing that's mostly a user admin issue, though (and you can just link
> >> to the full API and avoid the whole problem).
> >
> >
> > Do I understand correctly that the "user admin issue" means "add the
> > appropriate \DLLs to the PATH"?
> >
> > What I don't understand here is how linking to the full API avoids the
> > problem... it must put more python library code into the stub executable?
> > Enough to know how to search the registry to find the  dir>
> > for the version of Python from which the full API was obtained? Or
> something
> > else?
>
> Sorry, I assumed more Windows/C knowledge than you have.
>
> I'll work on this and produce proper binaries in due course, so you
> can always wait for them. But you can build the stub with pretty much
> anything, I suspect - I managed with MSVC 2010 and mingw. I'll add
> some build docs and get it on github.
>
> Using mingw
>
> gcc -Wall -O2 -o stub.exe stub.c -I \Include
> C:\Windows\system32\python34.dll
> strip -s stub.exe
>
> Using MSVC
>
> cl /Festub.exe /O2 stub.c /I\Include  home>\libs\python34.lib
>
> Regarding the DLLs, yes the "user admin issue" is adding the right
> directory to PATH. I used the phrase "admin issue" as it's the aspect
> that's likely to be far harder than any of the technical issues :-)
> The reason using the full API helps is that the full API references
> python34.dll rather than python3.dll. And the Python installer puts
> python34.dll on PATH automatically, as it's what the "python" command
> uses. (For the people with more Windows knowledge, I know this is a
> simplification, but it's close enough for now).
>
> So there are two  options with the code I posted.
>
> 1. Build an exe that uses a specific version of Python, but which will
> "just work" in basically the same way that the "python" command works.
> 2. Build an exe that works with any version of Python, but requires
> some setup from the user.
>
> Either approach requires that the Python DLL is on PATH, but that's
> far more likely with the version-specific one, just because of how the
> installer does things.
>
> With extra code, the stub could locate an appropriate Python DLL
> dynamically, which would simplify usage at the cost of a bit of fiddly
> code in the stub.
>
> This might be a useful addition to the zipapp module for Python 3.6.
>
> Paul
>
> PS Current launchers (py.exe, the entry point launchers from
> pip/setuptools, etc) tend to spawn the actual python program in a
> subprocess. I believe there are *technically* some differences in the
> runtime environment when you use an embedding approach like this, but
> I don't know what they are, and they probably won't affect 99.9% of
> users. Lack of support for binary extensions is likely to be way more
> significant.
> ___
> 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/rymg19%40gmail.com
>



-- 
Ryan
[ERROR]: Your autotools build scripts are 200 lines longer than your
program. Something’s wrong.
http://kirbyfan64.github.io/
___
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-arch

[Python-Dev] Where are bugs with the web site reported?

[Ryan Gonzalez]

I have encountered this weird issue on Chrome for Android where scrolling up 
just a little causes the page to dart to the top. I was going to report it in 
the bug tracker, but I didn't see a label for the web site itself.

Worst part is, this is stopping me from reading the humor page!

-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.___
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?

[Ryan Gonzalez]

Response from the Chrome devs:

This site has JS that reacts to the viewport resize event from top controls
showing by scrolling to the top.  I guess the intent might be to scroll to
the top when the phone rotates, and it overtriggers here.  I don't think
there's a short-term fix, but this seems like an interesting case to keep
in mind while evolving viewport resize behaviors.


On Thu, Jul 16, 2015 at 2:24 PM, Glenn Linderman 
wrote:

>  On 7/16/2015 12:11 PM, Ryan Gonzalez wrote:
>
> I have encountered this weird issue on Chrome for Android where scrolling
> up just a little causes the page to dart to the top. I was going to report
> it in the bug tracker, but I didn't see a label for the web site itself.
>
> Worst part is, this is stopping me from reading the humor page!
>
>
> Sounds more like a bug in Chrome than on the site, unless it is repeatable
> using other browsers, or unless the site has Chrome-specific code.
>
> ___
> 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/rymg19%40gmail.com
>
>


-- 
Ryan
[ERROR]: Your autotools build scripts are 200 lines longer than your
program. Something’s wrong.
http://kirbyfan64.github.io/
___
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 far to go with user-friendliness

[Ryan Gonzalez]

I am tempted to reply with a slightly sarcastic message involving a cookie...

On July 17, 2015 6:40:21 PM CDT, Antoine Pitrou  wrote:
>
>Frankly, this kind of inept discussion, where a bunch of folks get hung
>up about an extremely minor design decision (who cares whether "assret"
>is being special-cased or not? in the actual world, not the fantasy
>world of righteous indignation and armchair architects?), is amongst
>the reasons why I'm stopping contributing to CPython.
>
>Keep up the good work, you're making this place totally repulsive to
>participate in. Every maintainer or contributor now has an army of
>voluntary hair-splitters to bother about, most of whom probably aren't
>relying on said functionality to begin with.
>
>Regards
>
>Antoine.
>
>
>
>On Fri, 17 Jul 2015 15:11:59 -0700
>Ethan Furman  wrote:
>> On 07/16/2015 11:30 PM, Nick Coghlan wrote:
>> > On 17 July 2015 at 08:30, Ben Finney wrote:
>> 
>> >> By definition, advocating to not add cruft to an API is going to
>be in
>> >> advance of being bitten by those additions.
>> >
>> > That's not what people are doing. Folks are actually arguing for
>> > *restoring* the ability to mock out method names starting with
>> > "assret_*".
>> 
>> Why is that surprising?  As somebody already mentioned (Terry, I
>think?) "assret" is a fine abbreviation, as well as possibly being a
>foreign word.
>> 
>> > I still don't know why anyone thinks restoring that would be a
>> > worthwhile use of a maintainers' time (or why they thinking arguing
>in
>> > favour of such a capability is a worthwhile use of theirs).
>> 
>> 1) Because it shouldn't have been added in the first place.
>> 
>> 2) Because DWIM does not belong in Python.
>> 
>> > None of the perspectives presented in this thread are new, although
>> > the apparent obsession over such a minor detail has made it
>abundantly
>> > clear that this kind of helper simply isn't worth  the distraction
>it
>> > creates for maintainers, *regardless* of whether or not it helps
>end
>> > users.
>> 
>> To be clear:
>> 
>>- those who are upset over "assret" are not upset over "assert"
>> 
>>- it is not Python's job (nor the stdlib's) to correct spelling
>errors
>> 
>> --
>> ~Ethan~
>
>
>
>___
>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/rymg19%40gmail.com

-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.___
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 Issue-subprocess problem

[Ryan Gonzalez]

*before anyone else says it*

This list is for development *of* Python, not *in* Python. If you need help
with things like this, I'd advise you to use the python-list
 mailing list or Stack
Overflow .

On Thu, Aug 27, 2015 at 3:57 AM, Low, Wai HoeX 
wrote:

> Dear,
>
>
>
> I have faced a problem as below when I startup the python IDLE
>
>
>
> [image: cid:image001.png@01D0E0CE.454096D0]
>
>
>
> Then I try to run a simple program like this:
>
> [image: cid:image002.png@01D0E0CE.454096D0]
>
>
>
> Other issue is pop out
>
>
>
> [image: cid:image003.png@01D0E0CE.454096D0]
>
>
>
> May I know how to fix the issue? My laptop is window 7 64bits.
>
>
>
>
>
>
>
> Thanks and having a  nice day !
>
>
>
> Regards,
>
> Arthur Low Wai Hoe
>
>
>
> ___
> 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/rymg19%40gmail.com
>
>


-- 
Ryan
[ERROR]: Your autotools build scripts are 200 lines longer than your
program. Something’s wrong.
http://kirbyfan64.github.io/
___
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] What's New editing

[Ryan Gonzalez]

On September 5, 2015 12:27:26 PM CDT, David Mertz  wrote:
>I have to apologize profusely here.  Just after I offered to do this
>(and
>work even said it was OK in principle to do it on work time), my work
>load
>went through the roof.  And now it's really already later than most of
>it
>should have been done.  I'd still very much like to work on this, but I
>wonder if maybe someone else would like to be co-author since the
>increased
>workload doesn't actually seem likely to diminish soon.

So...

I also have a lot of stuff right now, but it's not that bad...could I help out 
here?


>
>On Wed, Sep 2, 2015 at 7:03 PM, Yury Selivanov
>
>wrote:
>
>>
>>
>> On 2015-07-06 11:38 AM, David Mertz wrote:
>>
>>> Hi Folks,
>>>
>>> I hereby volunteer to write "What's New for Python 3.5?" if folks on
>>> python-dev are fine with me taking the job (i.e. I ran it by Travis,
>my
>>> boss at Continuum, and he's happy to allow me to do that work within
>my
>>> salaried hours... so having time isn't a problem).
>>>
>>> If this is OK with the powers-that-be, I'll coordinate with David
>Murray
>>> on how best to take over this task from him.
>>>
>>
>> Hi David,
>>
>> Are you still going to work on what's new for 3.5?
>>
>> Yury
>>
>>
>> ___
>> 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/mertz%40gnosis.cx
>>

-- 
Sent from my Nexus 5 with K-9 Mail. Please excuse my brevity.
___
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: Collecting information about git

[Ryan Gonzalez]

On September 12, 2015 6:14:58 PM CDT, Tim Delaney  
wrote:
>On 13 September 2015 at 04:42, Oleg Broytman  wrote:
>
>>There are too many things that I personally can do with git but
>can't
>> do with hg. Because of that I switched all my development from hg to
>git
>> and I am willing to help those who want to follow.
>>
>
>Slightly off-topic, but personally I'd love to know what those are.
>I've
>yet to find anything in Git that I haven't been able to do at least as
>well
>with Mercurial (or an extension), and there are things Mercurial
>supports that I use extensively (in particular named branches and
>phases)
>where the concept doesn't even exist in Git.
>
>I switched all of my development to Mercurial, and use hg-git and
>hgsubversion when I need to interact with those systems.

...speed??

Seriously; just try pulling the entire CPython repo. Then try again with the 
GitHub mirror.

I love Mercurial's CLI. But, every time I use it, I end up feeling like I'm 
waiting forever.

Git's CLI is really weird, but it's surprisingly powerful and flexible once you 
get the hang of it (which admittedly might take a while!).

>
>Tim Delaney
>
>
>
>
>___
>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/rymg19%40gmail.com

-- 
Sent from my Nexus 5 with K-9 Mail. Please excuse my brevity.
___
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: Collecting information about git

[Ryan Gonzalez]

*cough* Google *cough*

http://stackoverflow.com/questions/5911774/git-gui-like-hg-workbench-in-ms-windows

SourceTree looks quite similar.


On Thu, Sep 17, 2015 at 2:07 PM, Terry Reedy  wrote:

> On 9/17/2015 3:17 AM, André Freitas wrote:
>
>> Regarding Git tools for Windows, GitHub Desktop and Sourcetree are
>> actually very good with nice features.
>>
>
> Do you know if either have anything like TortoiseHg Workbench?
> https://tortoisehg.readthedocs.org/en/latest/workbench.html
> (screenshot at top)
>
> --
> 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/rymg19%40gmail.com
>



-- 
Ryan
[ERROR]: Your autotools build scripts are 200 lines longer than your
program. Something’s wrong.
http://kirbyfan64.github.io/
___
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] Not Deprecating Arbitrary Function Annotations

[Ryan Gonzalez]

There is one reason I would be really freaking mad if they deprecated other 
uses of annotations:

https://pypi.python.org/pypi/plac

On October 5, 2015 1:55:37 PM CDT, Steve Wedig  wrote:
>Congratulations on the release of 3.5 and Pep 484. I've used Python
>professionally for 10 years and I believe type hints will make it
>easier to
>work with large codebases evolving over time. My only concern about Pep
>484
>is the discussion of whether or not to deprecate arbitrary function
>annotations.
>https://www.python.org/dev/peps/pep-0484/
>
>I would like to request that arbitrary function annotations are not
>deprecated for three reasons:
>1. Backwards Compatibility
>2. Type Experimentation
>3. Embedded Languages
>
>1. Backwards Compatibility
>After reading Pep 3107 my team has made significant use of non-standard
>annotations. It would be a serious burden to be forced to port our
>annotations back to decorators. This would also make our codebase
>considerably less readable because function annotations are much more
>readable than input/output annotations relegated to decorators.
>https://www.python.org/dev/peps/pep-3107/
>
>2. Type Experimentation
>Arbitrary function annotations allow developers to experiment with
>potential type system improvements in real projects. Ideas can be
>validated
>before officially adding them to the language. This seems like an
>advantage
>that should be preserved. After all, Pep 484 says it was strongly
>inspired
>by MyPy, an existing project.
>http://mypy-lang.org/
>
>3. Embedded Languages
>Python's flexibility makes it an amazing language to embed other
>languages
>in. In this regard, Python 3's addition of arbitrary function
>annotations
>and class decorators complements Python 2's dynamic typing, function
>decorators, reflection, metaclasses, properties, magic methods,
>generators,
>and keyword arguments. Arbitrary function annotations are a crucial
>part of
>this toolkit, and this feature is not available in most other
>languages.
>For anyone interested in the utility and mechanics of embedded
>languages,
>I'd recommend Martin Fowler's book: Domain Specific Languages.
>http://www.amazon.com/Domain-Specific-Languages-Addison-Wesley-Signature-Series/dp/0321712943
>
>So I agree with the course of action mentioned in Pep 484 that avoids
>runtime deprecation of arbitrary function annotation: "Another possible
>outcome would be that type hints will eventually become the default
>meaning
>for annotations, but that there will always remain an option to disable
>them." I would only add that there should be a way to disable type
>checking
>for an entire directory (recursively). This would be useful for
>codebases
>that have not been ported to standard annotations yet, and for
>codebases
>that will not be ported for the reasons listed above.
>
>Thanks for your consideration.
>
>Best,
>Steve
>
>
>
>
>___
>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/rymg19%40gmail.com

-- 
Sent from my Nexus 5 with K-9 Mail. Please excuse my brevity.
___
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] Not Deprecating Arbitrary Function Annotations

[Ryan Gonzalez]

PSF. Nothing personal, of course...

On October 5, 2015 3:01:11 PM CDT, Guido van Rossum  wrote:
>"They"?
>
>On Mon, Oct 5, 2015 at 12:57 PM, Ryan Gonzalez 
>wrote:
>
>> There is one reason I would be really freaking mad if they deprecated
>> other uses of annotations:
>>
>> https://pypi.python.org/pypi/plac
>>
>> On October 5, 2015 1:55:37 PM CDT, Steve Wedig 
>> wrote:
>> >Congratulations on the release of 3.5 and Pep 484. I've used Python
>> >professionally for 10 years and I believe type hints will make it
>> >easier to
>> >work with large codebases evolving over time. My only concern about
>Pep
>> >484
>> >is the discussion of whether or not to deprecate arbitrary function
>> >annotations.
>> >https://www.python.org/dev/peps/pep-0484/
>> >
>> >I would like to request that arbitrary function annotations are not
>> >deprecated for three reasons:
>> >1. Backwards Compatibility
>> >2. Type Experimentation
>> >3. Embedded Languages
>> >
>> >1. Backwards Compatibility
>> >After reading Pep 3107 my team has made significant use of
>non-standard
>> >annotations. It would be a serious burden to be forced to port our
>> >annotations back to decorators. This would also make our codebase
>> >considerably less readable because function annotations are much
>more
>> >readable than input/output annotations relegated to decorators.
>> >https://www.python.org/dev/peps/pep-3107/
>> >
>> >2. Type Experimentation
>> >Arbitrary function annotations allow developers to experiment with
>> >potential type system improvements in real projects. Ideas can be
>> >validated
>> >before officially adding them to the language. This seems like an
>> >advantage
>> >that should be preserved. After all, Pep 484 says it was strongly
>> >inspired
>> >by MyPy, an existing project.
>> >http://mypy-lang.org/
>> >
>> >3. Embedded Languages
>> >Python's flexibility makes it an amazing language to embed other
>> >languages
>> >in. In this regard, Python 3's addition of arbitrary function
>> >annotations
>> >and class decorators complements Python 2's dynamic typing, function
>> >decorators, reflection, metaclasses, properties, magic methods,
>> >generators,
>> >and keyword arguments. Arbitrary function annotations are a crucial
>> >part of
>> >this toolkit, and this feature is not available in most other
>> >languages.
>> >For anyone interested in the utility and mechanics of embedded
>> >languages,
>> >I'd recommend Martin Fowler's book: Domain Specific Languages.
>> >
>>
>http://www.amazon.com/Domain-Specific-Languages-Addison-Wesley-Signature-Series/dp/0321712943
>> >
>> >So I agree with the course of action mentioned in Pep 484 that
>avoids
>> >runtime deprecation of arbitrary function annotation: "Another
>possible
>> >outcome would be that type hints will eventually become the default
>> >meaning
>> >for annotations, but that there will always remain an option to
>disable
>> >them." I would only add that there should be a way to disable type
>> >checking
>> >for an entire directory (recursively). This would be useful for
>> >codebases
>> >that have not been ported to standard annotations yet, and for
>> >codebases
>> >that will not be ported for the reasons listed above.
>> >
>> >Thanks for your consideration.
>> >
>> >Best,
>> >Steve
>> >
>> >
>>
>>
>> >
>> >___
>> >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/rymg19%40gmail.com
>>
>> --
>> Sent from my Nexus 5 with K-9 Mail. Please excuse my brevity.
>> ___
>> 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/guido%40python.org
>>
>
>
>
>-- 
>--Guido van Rossum (python.org/~guido)

-- 
Sent from my Nexus 5 with K-9 Mail. Please excuse my brevity.___
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] Not Deprecating Arbitrary Function Annotations

[Ryan Gonzalez]

Uh, I kind of knew that. Then I rushed the email and my brain momentarily left 
me. Sorry...

On October 5, 2015 3:23:29 PM CDT, Guido van Rossum  wrote:
>Maybe I should clarify how the process of changing the language works.
>
>The PSF doesn't enter into it -- they manage the infrastructure (e.g.
>mailing lists, Hg repo, tracker, python.org) but they don't have
>anything
>to do with deciding how or when the language changes.
>
>Language changes are done *here* by *us* all. Anyone can write a PEP
>and it
>will be discussed here (but first in python-ideas of course).
>
>I'm sorry you don't feel more included, but I really don't like the
>idea of
>"us vs. them" in this list. We're all working together to make Python
>the
>best language it can be.
>
>--Guido
>
>On Mon, Oct 5, 2015 at 1:18 PM, Ryan Gonzalez  wrote:
>
>> PSF. Nothing personal, of course...
>>
>>
>> On October 5, 2015 3:01:11 PM CDT, Guido van Rossum
>
>> wrote:
>>>
>>> "They"?
>>>
>>> On Mon, Oct 5, 2015 at 12:57 PM, Ryan Gonzalez 
>wrote:
>>>
>>>> There is one reason I would be really freaking mad if they
>deprecated
>>>> other uses of annotations:
>>>>
>>>> https://pypi.python.org/pypi/plac
>>>>
>>>> On October 5, 2015 1:55:37 PM CDT, Steve Wedig
>
>>>> wrote:
>>>> >Congratulations on the release of 3.5 and Pep 484. I've used
>Python
>>>> >professionally for 10 years and I believe type hints will make it
>>>> >easier to
>>>> >work with large codebases evolving over time. My only concern
>about Pep
>>>> >484
>>>> >is the discussion of whether or not to deprecate arbitrary
>function
>>>> >annotations.
>>>> >https://www.python.org/dev/peps/pep-0484/
>>>> >
>>>> >I would like to request that arbitrary function annotations are
>not
>>>> >deprecated for three reasons:
>>>> >1. Backwards Compatibility
>>>> >2. Type Experimentation
>>>> >3. Embedded Languages
>>>> >
>>>> >1. Backwards Compatibility
>>>> >After reading Pep 3107 my team has made significant use of
>non-standard
>>>> >annotations. It would be a serious burden to be forced to port our
>>>> >annotations back to decorators. This would also make our codebase
>>>> >considerably less readable because function annotations are much
>more
>>>> >readable than input/output annotations relegated to decorators.
>>>> >https://www.python.org/dev/peps/pep-3107/
>>>> >
>>>> >2. Type Experimentation
>>>> >Arbitrary function annotations allow developers to experiment with
>>>> >potential type system improvements in real projects. Ideas can be
>>>> >validated
>>>> >before officially adding them to the language. This seems like an
>>>> >advantage
>>>> >that should be preserved. After all, Pep 484 says it was strongly
>>>> >inspired
>>>> >by MyPy, an existing project.
>>>> >http://mypy-lang.org/
>>>> >
>>>> >3. Embedded Languages
>>>> >Python's flexibility makes it an amazing language to embed other
>>>> >languages
>>>> >in. In this regard, Python 3's addition of arbitrary function
>>>> >annotations
>>>> >and class decorators complements Python 2's dynamic typing,
>function
>>>> >decorators, reflection, metaclasses, properties, magic methods,
>>>> >generators,
>>>> >and keyword arguments. Arbitrary function annotations are a
>crucial
>>>> >part of
>>>> >this toolkit, and this feature is not available in most other
>>>> >languages.
>>>> >For anyone interested in the utility and mechanics of embedded
>>>> >languages,
>>>> >I'd recommend Martin Fowler's book: Domain Specific Languages.
>>>> >
>>>>
>http://www.amazon.com/Domain-Specific-Languages-Addison-Wesley-Signature-Series/dp/0321712943
>>>> >
>>>> >So I agree with the course of action mentioned in Pep 484 that
>avoids
>>>> >runtime deprecation of arbitrary function annotation: "Another
>possible
>>>> >outcome would be that type hints will eventually become the
>default
>>>>

[Python-Dev] Should PEP 498 specify if rf'...' is valid?

[Ryan Gonzalez]

It mentions fr'...' as a formatted raw string but doesn't say anything about 
rf'...'. Right now, in implementing PEP 498 support in Howl 
(https://github.com/howl-editor/howl/pull/118 and 
https://github.com/howl-editor/howl/commit/1e577da89efc1c1de780634b531f64346cf586d6#diff-851d9b84896270cc7e3bbea3014007a5R86),
 I assumed both were valid. Should the PEP be more specific?

BTW, at the rate language-python is going, GitHub will get syntax highlighting 
for f-strings in 2050. :D
-- 
Sent from my Nexus 5 with K-9 Mail. Please excuse my brevity.___
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] Should PEP 498 specify if rf'...' is valid?

[Ryan Gonzalez]

Ah, I missed that part. Sorry! :/

On October 22, 2015 7:27:41 AM CDT, "Eric V. Smith"  wrote:
>On 10/22/2015 7:32 AM, Eric V. Smith wrote:
>> On 10/21/2015 10:57 PM, Ryan Gonzalez wrote:
>>> It mentions fr'...' as a formatted raw string but doesn't say
>anything
>>> about rf'...'. Right now, in implementing PEP 498 support in Howl
>>> (https://github.com/howl-editor/howl/pull/118 and
>>>
>https://github.com/howl-editor/howl/commit/1e577da89efc1c1de780634b531f64346cf586d6#diff-851d9b84896270cc7e3bbea3014007a5R86),
>>> I assumed both were valid. Should the PEP be more specific?
>> 
>> Yes, I'll add some wording.
>
>Now that I check, in the Specification section, the PEP already says
>"'f' may be combined with 'r', in either order, to produce raw f-string
>literals". So I think this case is covered, no?
>
>Eric.

-- 
Sent from my Nexus 5 with K-9 Mail. Please excuse my brevity.___
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] Should PEP 498 specify if rf'...' is valid?

[Ryan Gonzalez]

On October 22, 2015 11:10:48 AM CDT, "Sven R. Kunze"  wrote:
>On 22.10.2015 13:32, Eric V. Smith wrote:
>> ['B', 'BF', 'BFR', 'BFr', 'BR', 'BRF', 'BRf', 'Bf', 'BfR', 'Bfr',
>'Br',
>> 'BrF', 'Brf', 'F', 'FB', 'FBR', 'FBr', 'FR', 'FRB', 'FRb', 'Fb',
>'FbR',
>> 'Fbr', 'Fr', 'FrB', 'Frb', 'R', 'RB', 'RBF', 'RBf', 'RF', 'RFB',
>'RFb',
>> 'Rb', 'RbF', 'Rbf', 'Rf', 'RfB', 'Rfb', 'U', 'b', 'bF', 'bFR', 'bFr',
>> 'bR', 'bRF', 'bRf', 'bf', 'bfR', 'bfr', 'br', 'brF', 'brf', 'f',
>'fB',
>> 'fBR', 'fBr', 'fR', 'fRB', 'fRb', 'fb', 'fbR', 'fbr', 'fr', 'frB',
>> 'frb', 'r', 'rB', 'rBF', 'rBf', 'rF', 'rFB', 'rFb', 'rb', 'rbF',
>'rbf',
>> 'rf', 'rfB', 'rfb', 'u']
>>
>> I think the upper/lower ones are nuts, but it's probably too late to
>do
>> anything about it. 'FbR', really?
>
>Why not disallowing them?
>
>I for one could live with all-lower-case AND a predefined order.
>

Well, now it's backwards-compatibility.

>Best,
>Sven
>___
>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/rymg19%40gmail.com

-- 
Sent from my Nexus 5 with K-9 Mail. Please excuse my brevity.
___
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] Should PEP 498 specify if rf'...' is valid?

[Ryan Gonzalez]

But it'd be weird now if fR worked but fbR didn't.

On Thu, Oct 22, 2015 at 12:02 PM, Sven R. Kunze  wrote:

> On 22.10.2015 18:17, Ryan Gonzalez wrote:
>
>>
>>> anything about it. 'FbR', really?
>>>>
>>> Why not disallowing them?
>>>
>>> I for one could live with all-lower-case AND a predefined order.
>>>
>>> Well, now it's backwards-compatibility.
>>
>
> Huh? There are no fb strings yet.
>
> Best,
> Sven
>



-- 
Ryan
[ERROR]: Your autotools build scripts are 200 lines longer than your
program. Something’s wrong.
http://kirbyfan64.github.io/
___
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] If you shadow a module in the standard library that IDLE depends on, bad things happen

[Ryan Gonzalez]

Why not just check the path of the imported modules and compare it with the 
Python library directory?

On October 29, 2015 3:26:08 PM CDT, Mark Roseman  wrote:
>Laura, I think what you want should actually be more-or-less doable in
>IDLE.
>
>The main routine that starts IDLE should be able to detect if it starts
>correctly (something unlikely to happen if a significant stdlib module
>is shadowed), watch for an attribute error of that form and try to
>determine if shadowing is the cause, and if so, reissue a saner error
>message.
>
>The subprocess/firewall error is occurring because the ‘string’ problem
>in your example isn’t being hit right away so a few startup things
>already are happening. The point where we’re showing that error (as a
>result of a timeout) should be able to check as per the above that IDLE
>was able to start alright, and if not, change or ignore the timeout
>error.
>
>There’ll probably be some cases (depending on exactly what gets
>shadowed) that may be difficult to get to work, but it should be able
>to handle most things.
>
>Mark
>
>___
>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/rymg19%40gmail.com

-- 
Sent from my Nexus 5 with K-9 Mail. Please excuse my brevity.___
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] If you shadow a module in the standard library that IDLE depends on, bad things happen

[Ryan Gonzalez]

Well, tell your friend that that means middle and high schoolers must think
alike! :D

On Thu, Oct 29, 2015 at 4:18 PM, Laura Creighton  wrote:

> In a message of Thu, 29 Oct 2015 15:50:30 -0500, Ryan Gonzalez writes:
> >Why not just check the path of the imported modules and compare it with
> the Python library directory?
>
> My friend Åsa who is 12 years old suggested exactly this at the club.  If
> this
> works then I will be certain to mention this to her.  I said that I would
> ask 'how hard is this?'
>
> Laura
>



-- 
Ryan
[ERROR]: Your autotools build scripts are 200 lines longer than your
program. Something’s wrong.
http://kirbyfan64.github.io/
___
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] If you shadow a module in the standard library that IDLE depends on, bad things happen

[Ryan Gonzalez]

Well, this works on Python 2 only (I'm on a phone with only access to 2 right 
now), but this is a start (apologies for the screwy syntax highlighting):

import sys, imp, logging, os

modules = '''
imp
string
...
'''.split()

class StdlibTester(object):
base = os.path.dirname(os.__file__) # hack; is there a better way to do 
this?

def find_module(self, fullname, path=None):
if fullname in modules:
self.path = path
return self
return None

def load_module(self, name):
if name in sys.modules:
return sys.modules[name]
module_info = imp.find_module(name, self.path)
module = imp.load_module(name, *module_info)
sys.modules[name] = module

if hasattr(module, '__file__') and not 
os.path.dirname(module.__file__).startswith(self.base):
logging.warning('stdlib module %s was overriden', name)

return module

sys.meta_path.append(StdlibTester())
import string


On October 29, 2015 7:06:51 PM CDT, "R. David Murray"  
wrote:
>On Thu, 29 Oct 2015 16:56:38 -0700, Nathaniel Smith 
>wrote:
>> On Thu, Oct 29, 2015 at 1:50 PM, Ryan Gonzalez 
>wrote:
>> > Why not just check the path of the imported modules and compare it
>with the
>> > Python library directory?
>> 
>> It works, but it requires that everyone who could run into this
>> problem carefully add some extra guard code to every stdlib import
>> statement, and in practice nobody will (or at least, not until after
>> they've already gotten bitten by this at least once... at which point
>> they no longer need it).
>> 
>> Given that AFAICT there's no reason this couldn't be part of the
>> default import system's functionality and "just work" for everyone,
>if
>> I were going to spend time on trying to fix this I'd probably target
>> that :-).
>> 
>> (I guess the trickiest bit would be to find an efficient and
>> maintainable way to check whether a given package name is present in
>> the stdlib.)
>
>For Idle, though, it sounds like a very viable strategy, and that's
>what Laura is concerned about.
>
>--David
>___
>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/rymg19%40gmail.com

-- 
Sent from my Nexus 5 with K-9 Mail. Please excuse my brevity.___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] 2.7.11 plans

[Ryan Gonzalez]

On Sun, Nov 1, 2015 at 4:42 PM, Benjamin Peterson 
wrote:

> Happy November, everyone. It’s nearly time for the next semi-annual
> instalment of the 2.7 series. I’m planning to release a 2.7.11 release
> candidate on November 21st and 2.7.11 final on December 5.
>
> More than half-done releasing 2.7-ly yours,
>

This made me laugh!



> Benjamin
> ___
> 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/rymg19%40gmail.com
>



-- 
Ryan
[ERROR]: Your autotools build scripts are 200 lines longer than your
program. Something’s wrong.
http://kirbyfan64.github.io/
___
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] modernizing IDLE

[Ryan Gonzalez]

On Tue, Nov 10, 2015 at 5:02 PM, Michiel Overtoom  wrote:

>
> > On 06 Nov 2015, at 18:08, Mark Roseman  wrote:
> >
> > (There’s also currently a post on Hacker News about this).
>
> You have a link for that HN item? I've looked at the first five pages but
> couldn't find it.
>
>
https://news.ycombinator.com/item?id=10519785

I used the big "Search" box at the bottom of the main Hacker News page. ;)


> Greetings,
>
> ___
> 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/rymg19%40gmail.com
>



-- 
Ryan
[ERROR]: Your autotools build scripts are 200 lines longer than your
program. Something’s wrong.
http://kirbyfan64.github.io/
___
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] Reading Python source file

[Ryan Gonzalez]

Well, not quite the same thing, but 
https://github.com/kirbyfan64/pfbuild/blob/master/pfbuild embeds the compressed 
version of 16k LOC. Would it be affected negatively in any way be this?

Since all the data is on one line, I'd think the old (current) parser would end 
up reading in the whole line anyway.

On November 18, 2015 9:48:41 AM CST, Guido van Rossum  wrote:
>On Wed, Nov 18, 2015 at 4:15 AM, Hrvoje Niksic 
>wrote:
>> On 11/18/2015 03:31 AM, Nick Coghlan wrote:
>>>
>>> That behaviour is then inherited at the command line by both the -m
>>> switch and the support for executing directories and zip archives.
>>> When we consider that the "-c" switch also executes an in-memory
>>> string, direct script execution is currently the odd one out in
>*not*
>>> reading the entire source file into memory first, so Serhiy's
>proposed
>>> simplification of the implementation makes sense to me.
>>
>>
>> Reading the whole script in memory will incur an overhead when
>executing
>> scripts that contain (potentially large) data embedded after the end
>of
>> script source.
>>
>> The technique of reading data from sys.argv[0] is probably obsolete
>now that
>> Python supports executing zipped archives, but it is popular in shell
>> scripting and might still be used for self-extracting scripts that
>must
>> support older Python versions. This feature doesn't affect imports
>and -c
>> which are not expected to contain non-Python data.
>
>That trick doesn't work unless the data looks like Python comments or
>data (e.g. a docstring). Python has always insisted on being able to
>parse until EOF. The only extreme case would be a small script
>followed by e.g. 4 GB of comments (where the old parser would indeed
>be more efficient). But unless you can point me to an occurrence of
>this in the wild I'm going to speculate that you just made this up
>based on the shell analogy (which isn't perfect).
>
>-- 
>--Guido van Rossum (python.org/~guido)
>___
>Python-Dev mailing list
>Python-Dev@python.org
>https://mail.python.org/mailman/listinfo/python-dev
>Unsubscribe:
>https://mail.python.org/mailman/options/python-dev/rymg19%40gmail.com

-- 
Sent from my Nexus 5 with K-9 Mail. Please excuse my brevity.___
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.exe is not a valid Win32 app"

[Ryan Gonzalez]

Did you get the x86-64 version or x86? If you had gotten the former, it would 
lead to that error.

On December 1, 2015 8:30:25 AM CST, Alexei Belenki via Python-Dev 
 wrote:
>Installed python 3.5 (from https://www.python.org/downloads/) on
>Windows XPsp3/32
>On starting >>python.exe got the text above in the Windows message box.
>Any suggestions?Thanks.AB
>
>
>
>___
>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/rymg19%40gmail.com

-- 
Sent from my Nexus 5 with K-9 Mail. Please excuse my brevity.___
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 Language Reference has no mention of list comÃprehensions

[Ryan Gonzalez]

On December 3, 2015 8:26:23 AM CST, Laura Creighton  wrote:
>In a message of Thu, 03 Dec 2015 13:37:17 +, Paul Moore writes:
>>On 3 December 2015 at 12:51, Laura Creighton  wrote:
>>> Intentional or Oversight?
>>
>>Hard to find :-)
>>
>>https://docs.python.org/3/reference/expressions.html#displays-for-lists-sets-and-dictionaries
>>
>>I went via "Atoms" in the expression section, then followed the links
>>in the actual grammar spec.
>>
>>Paul
>
>I think the whole use of the language displays as in
>  
>  6.2.4. Displays for lists, sets and dictionaries
>
>  For constructing a list, a set or a dictionary Python provides 
>  special syntax called “displays”, each of them in two flavors:
>
>either the container contents are listed explicitly, or
>they are computed via a set of looping and filtering instructions, 
>called a comprehension.
>
>is very odd.  I don't know anybody who talks of 'displays'.  They
>talk of 'two ways to construct a'.  
>
>Who came up with the word 'display' and what does it have going for
>it that I have missed?  Right now I think its chief virtue is that
>it is a meaningless noun.  (But not meaningless enough, as I
>associate displays with output, not construction).
>
>I think that 
>
>6.2.4 Constructing lists, sets and dictionaries
>
>would be a much more useful title, and
>
>6.2.4 Constructing lists, sets and dictionaries -- explicitly or
>through the use of comprehensions
>

What about:

6.2.4 Constricting lists, sets, and dictionaries (including comprehensions)

or something to that effect?

>an even better one.
>
>Am I missing something important about the 'display' language?
>
>Laura
>___
>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/rymg19%40gmail.com

-- 
Sent from my Nexus 5 with K-9 Mail. Please excuse my brevity.
___
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 Language Reference has no mention of list comÃprehensions

[Ryan Gonzalez]

On December 3, 2015 10:09:56 AM CST, Ryan Gonzalez  wrote:
>
>
>On December 3, 2015 8:26:23 AM CST, Laura Creighton 
>wrote:
>>In a message of Thu, 03 Dec 2015 13:37:17 +, Paul Moore writes:
>>>On 3 December 2015 at 12:51, Laura Creighton  wrote:
>>>> Intentional or Oversight?
>>>
>>>Hard to find :-)
>>>
>>>https://docs.python.org/3/reference/expressions.html#displays-for-lists-sets-and-dictionaries
>>>
>>>I went via "Atoms" in the expression section, then followed the links
>>>in the actual grammar spec.
>>>
>>>Paul
>>
>>I think the whole use of the language displays as in
>>  
>>  6.2.4. Displays for lists, sets and dictionaries
>>
>>  For constructing a list, a set or a dictionary Python provides 
>>  special syntax called “displays”, each of them in two flavors:
>>
>>either the container contents are listed explicitly, or
>>they are computed via a set of looping and filtering instructions,
>
>>called a comprehension.
>>
>>is very odd.  I don't know anybody who talks of 'displays'.  They
>>talk of 'two ways to construct a'.  
>>
>>Who came up with the word 'display' and what does it have going for
>>it that I have missed?  Right now I think its chief virtue is that
>>it is a meaningless noun.  (But not meaningless enough, as I
>>associate displays with output, not construction).
>>
>>I think that 
>>
>>6.2.4 Constructing lists, sets and dictionaries
>>
>>would be a much more useful title, and
>>
>>6.2.4 Constructing lists, sets and dictionaries -- explicitly or
>>through the use of comprehensions
>>
>
>What about:
>
>6.2.4 Constricting lists, sets, and dictionaries (including
>comprehensions)
>

Whoops! I meant "Constructing", not "Constricting". Pythons definitely 
constrict their prey, but that's not what I was referring to...

>or something to that effect?
>
>>an even better one.
>>
>>Am I missing something important about the 'display' language?
>>
>>Laura
>>___
>>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/rymg19%40gmail.com

-- 
Sent from my Nexus 5 with K-9 Mail. Please excuse my brevity.
___
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] New poll about a macro for safe reference replacing

[Ryan Gonzalez]

On December 16, 2015 8:12:47 AM CST, Serhiy Storchaka  
wrote:
>I'm bringing this up again, since the results of the previous poll did 
>not give an unambiguous result. Related links: [1], [2], [3], [4].
>
>Let me remind you that we are talking about adding the following macro.
>
>It is needed for safe replacement links. For now there is at least one 
>open crash report that can be solved with this macro [5] (I think there
>
>is yet one, but can't find it just now). And 50 potential bugs for
>which 
>we just still do not have a reproducer.
>
>#define Py_XXX(ptr, value)\
> { \
> PyObject *__tmp__ = ptr;  \
> ptr = new_value;  \
> Py_DECREF(__tmp__);   \
> }
>
>The problem is only in the macro name. There are objections against any
>
>proposed name, and no one name gained convincing majority.
>
>Here are names gained the largest numbers of votes plus names proposed 
>during polling.
>
>1. Py_SETREF
>2. Py_DECREF_REPLACE
>3. Py_REPLACE
>4. Py_SET_POINTER
>5. Py_SET_ATTR
>6. Py_REPLACE_REF
>

5 kinda sucks, since this has virtually nothing to do with attributes. 3 sounds 
like it does an operation on the object itself. 4 sounds stupid.

So:

1. +0
2. +0.5
3. -1
4. -1
5. -1
6. +1

>Please put your vote (a floating number from -1 to 1 including) for 
>every of proposed name. You also can propose new name.
>

Py_RESET? Like C++'s shared_ptr::reset: 
http://en.cppreference.com/w/cpp/memory/shared_ptr/reset.

>
>[1] https://mail.python.org/pipermail/python-dev/2008-May/079862.html
>[2] http://comments.gmane.org/gmane.comp.python.devel/145346
>[3] http://comments.gmane.org/gmane.comp.python.devel/145974
>[4] http://bugs.python.org/issue20440
>[5] http://bugs.python.org/issue24103
>
>___
>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/rymg19%40gmail.com

-- 
Sent from my Nexus 5 with K-9 Mail. Please excuse my brevity.
___
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] GitHub migration planning has started

[Ryan Gonzalez]

Is it possible to contribute to this, even if you're not part of the core dev 
team?

On January 10, 2016 11:43:48 AM CST, Brett Cannon  wrote:
>For those of you who have not heard, I made the decision a little over
>a
>week ago to move Python's development from our home-grown workflow to
>one
>hosted on GitHub (mainly for code hosting and code review; we're
>keeping
>bugs.python.org for our issue tracker). The hope is that this will let
>core
>developers work through patches faster so that we have a better
>turn-around
>time while being at least as good as our current workflow for external
>contributors (but I will be shocked if it isn't better). There are also
>people involved with the migration who plan to put in the effort to
>make
>sure external contributors can still submit patches without ever
>interacting with GitHub.
>
>If you want to help with the transition, then feel free to join the
>core-workflow mailing list where all the discussions on the details of
>the
>migration are occurring (including the PEP I'm starting to write to
>outline
>the steps we will be taking):
>https://mail.python.org/mailman/listinfo/core-workflow
>
>
>
>
>___
>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/rymg19%40gmail.com

-- 
Sent from my Nexus 5 with K-9 Mail. Please excuse my brevity.___
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] FAT Python (lack of) performance

[Ryan Gonzalez]

On January 25, 2016 9:32:07 PM CST, INADA Naoki  wrote:
>On Tue, Jan 26, 2016 at 12:02 PM, Andrew Barnert 
>wrote:
>
>> On Jan 25, 2016, at 18:21, INADA Naoki 
>wrote:
>> >
>> > I'm very interested in it.
>> >
>> > Ruby 2.2 and PHP 7 are faster than Python 2.
>> > Python 3 is slower than Python 2.
>>
>> Says who?
>>
>
>For example, http://benchmarksgame.alioth.debian.org/u64q/php.html
>In Japanese, many people compares language performance by microbench
>like
>fibbonacci.
>

...does writing Fibonacci in a foreign language make a performance difference? 
Or did you mean "In Japan?"

>
>>
>> That was certainly true in the 3.2 days, but nowadays, most things
>that
>> differ seem to be faster in 3.x.
>
>
>Python is little faster than ever in these years.
>But PHP and Ruby are much more faster than these years.
>
>Matz announced Ruby 3x3. Ruby hackers will make more effort to optimize
>ruby.
>http://engineering.appfolio.com/appfolio-engineering/2015/11/18/ruby-3x3
>
>
>
>> Maybe it's just the kinds of programs I write, but speedup in
>decoding
>> UTF-8 that's usually ASCII (and then processing the decoded unicode
>when
>> it's usually 1/4th the size), faster listcomps, and faster datetime
>seem to
>> matter more than slower logging or slower imports. And that's just
>when
>> running the same code; when you actually use new features, yield from
>is
>> much faster than looping over yield; scandir blows away listdir;
>asyncio
>> blows away asyncore or threading even harder; etc.
>>
>
>I know.
>But people compares language speed by simple microbench like
>fibbonacci.
>They doesn't use listcomp or libraries to compare *language* speed.
>
>
>> Maybe if you do different things, you have a different experience.
>But if
>> you have a specific problem, you'd do a lot better to file specific
>bugs
>> for that problem than to just hope that everything magically gets so
>much
>> faster that your bottleneck no longer matters.
>>
>
>I did it sometimes.
>But I'd like to base language performance like function call more
>faster.
>
>
>>
>> > Performance is a attractive feature.  Python 3 lacks it.
>>
>> When performance matters, people don't use Python 2, Ruby, or PHP,
>any
>> more than they use Python 3. Or, rather, they use _any_ of those
>languages
>> for the 95% of their code that doesn't matter, and C (often through
>> existing libraries like NumPy--and try to find a good equivalent of
>that
>> for Ruby or PHP) for the 5% that does.
>
>
>In the case of Web devs, many people choose main language from PHP,
>Ruby
>and Python.
>When peformance matters, they choose sub language from node.js, Go and
>Scala.
>
>While performance is not a matter when choosing first language, slowest
>of
>three makes bad impression
>and people feel less attractive about Python.

-- 
Sent from my Nexus 5 with K-9 Mail. Please excuse my brevity.
___
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] FAT Python (lack of) performance

[Ryan Gonzalez]

On January 25, 2016 9:59:36 PM CST, Chris Angelico  wrote:
>On Tue, Jan 26, 2016 at 2:32 PM, INADA Naoki 
>wrote:
>>
>> I know.
>> But people compares language speed by simple microbench like
>fibbonacci.
>> They doesn't use listcomp or libraries to compare *language* speed.
>>
>
>Well, that's a stupid way to decide on a language. Here, look: Python
>is faster than C. Proof!
>
>rosuav@sikorsky:~$ time python3 fib.py
>2880067194370816120
>
>real 0m0.033s
>user 0m0.032s
>sys 0m0.000s
>rosuav@sikorsky:~$ cat fib.py
>import functools
>
>@functools.lru_cache()
>def fib(n):
>if n < 2: return n
>return fib(n-2) + fib(n-1)
>
>print(fib(90))
>
>rosuav@sikorsky:~$ gcc fib.c && time ./a.out
>1134903170
>
>real 0m9.104s
>user 0m9.064s
>sys 0m0.000s
>rosuav@sikorsky:~$ cat fib.c
>#include 
>
>unsigned long fib(unsigned long n)
>{
>if (n < 2) return n;
>return fib(n-2) + fib(n-1);
>}
>
>int main()
>{
>printf("%lu\n",fib(45));
>}
>

*cough* -O3 *cough*

>
>Algorithmic differences - even subtle ones - can easily outdo choice
>of language for run-time performance. And if you try to write a true C
>equivalent of that Python code, good luck - I'll have the Python one
>written and running while you're still trying to figure out how to
>write a cache, much less how to keep the syntax clean as you add a
>cache to an existing function.
>
>Of course, rewriting the whole thing to work iteratively instead of
>double-recursively will make a dramatic difference to both programs.
>That's an unsubtle algorithmic difference, and if you're coding like
>that, you probably can't see the difference in performance between any
>two languages at anything up to a machine word (about the 90th or so
>Fibonacci number, on a 64-bit system) - all you'll see is the startup
>performance. As soon as you go beyond a machine word, Python massively
>trumps C, because its default integer type is a bignum. Going beyond a
>machine word in C is a hassle. Going beyond a machine word in Python 2
>is almost insignificant - hey look, now your repr has an 'L' on the
>end, and performance is immeasurably worse. In Python 3, there's no
>machine word whatsoever.
>
>So, yeah... Python beats C for Fibonacci calculation, too. You just
>have to not be stupid with your benchmarking.
>
>ChrisA
>___
>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/rymg19%40gmail.com

-- 
Sent from my Nexus 5 with K-9 Mail. Please excuse my brevity.
___
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] Fun with ancient unsupported platforms

[Ryan Gonzalez]

win16 doesn't seem to have important stuff:

https://github.com/python/cpython/search?utf8=✓&q="win16";

On January 28, 2016 8:57:20 AM CST, Larry Hastings  wrote:
>
>
>Check out and cd into Python trunk.
>
>% grep -Ri win16 * | wc
>  10  66 625
>
>% grep -Ri nextstep | wc
>  23 1191328
>
>% grep -Ri rhapsody * | wc
>  47 2693390
>
>% grep -Ri msdos * | wc
>  56 3813895
>  % grep -Ri ms-dos * | wc
>  20 1801425
>
>
>win16!  *laughs* *wipes tear from eye*
>
>It's currently 2016.  Perhaps it's time to remove all vestiges of these
>
>unsupported operating systems nobody's cared about since a year that 
>started with a '1'?
>
>
>//arry/
>
>p.s. I suspect some of the uses of "rhapsody" are actually live code 
>used for OS X.  So this isn't necessarily dead code, some of it is 
>merely long-out-of-date comments.
>
>p.p.s. At least there were no references to "taligent", "copland", or 
>"gershwin"...!
>
>
>
>
>___
>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/rymg19%40gmail.com

-- 
Sent from my Nexus 5 with K-9 Mail. Please excuse my brevity.___
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] The future of Python: fixing broken error handling in Python 8

[Ryan Gonzalez]

Python's exception handling system is currently badly brokeTypeError:
unsupported operand type(s) for +: 'NoneType' and 'NoneType'n. Therefore,
with the recent news of the joyous release of Python 8 (
https://mail.python.org/pipermail/python-dev/2016-March/143603.html), I
have decided to propose a revolutionary idea: safe mock objects.

A "safe" mock object (qualified name
`_frozensafemockobjectimplementation.SafeMockObjectThatIsIncludedWithPython8`;
Java-style naming was adopted for readability purposes; comments are now no
longer necessary) is a magic object that supports everything and returns
itself. Since examples speak more words than are in the Python source code,
here are some (examples, not words in the Python source code):


a = 1
b = None
c = a + b # Returns a
_frozensafemockobjectimplementation.SafeMockObjectThatIsIncludedWithPython8
print(c) # Prints the empty string.
d = c+1 # All operations on
`_frozensafemockobjectimplementation.SafeMockObjectThatIsIncludedWithPython8`'s
return a new one.
e = d.xyz(1, 2, 3) # `e` is now a
`_frozensafemockobjectimplementation.SafeMockObjectThatIsIncludedWithPython8`.
def f():
assert 0 # Causes the function to return a
`_frozensafemockobjectimplementation.SafeMockObjectThatIsIncludedWithPython8`.
raise 123 # Does the same thing.
print(L) # L is undefined, so it becomes a
`_frozensafemockobjectimplementation.SafeMockObjectThatIsIncludedWithPython8`.


Safe mock objects are obviously the Next Error Handling Revolution ™.
Unicode
errors now simply disappear and return more
`_frozensafemockobjectimplementation.SafeMockObjectThatIsIncludedWithPython8`s.

As for `try` and `catch` (protest the naming of `except`!!) statements,
they will
be completely ignored. The `try`, `except`, and `finally` bodies will all be
executed in sequence, except that printing and returning values with an
`except`
statement does nothing:


try:
xyz = None.a # `xyz` becomes a
`_frozensafemockobjectimplementation.SafeMockObjectThatIsIncludedWithPython8`.
except:
print(123) # Does nothing.
return None # Does nothing.
finally:
return xyz # Returns a
`_frozensafemockobjectimplementation.SafeMockObjectThatIsIncludedWithPython8`.


Aggressive error handling (as shown in PanicSort [https://xkcd.com/1185/])
that does destructive actions (such as `rm -rf /`) will always execute the
destructive code, encouraging more honest development.

In addition, due to errors simply being ignored, nothing can ever quite go
wrong.
All discussions about a safe navigation operator can now be immediately
halted,
since any undefined attributes will simply return a
`_frozensafemockobjectimplementation.SafeMockObjectThatIsIncludedWithPython8`.

Although I have not yet destroy--I mean, improved CPython to allow for this
amazing idea, I have created a primitive implementation of the
`_frozensafemockobjectimplementation` module:

https://github.com/kirbyfan64/_frozensafemockobjectimplementation

I hope you will all realize that this new idea is a drastic improvement
over current technologies and therefore support it, because we can Make
Python Great Again™.

-- 
Ryan
[ERROR]: Your autotools build scripts are 200 lines longer than your
program. Something’s wrong.
http://kirbyfan64.github.io/
___
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] Which version is better? Phyton 27 or Phyton 35?

[Ryan Gonzalez]

Well, based on recent feedback, you should wait for Phyton 80, which will
also make your bean plants start growing hair.

(Side note: This is seriously weird. :O )

--
Ryan
[ERROR]: Your autotools build scripts are 200 lines longer than your
program. Something’s wrong.
http://kirbyfan64.github.io/
Hi,

I am having a hard time trying to choose one of this two products:

Phyton 27:
http://www.amazon.com/Phyton-27-Systemic-Bactericide-Fungicide/dp/B00VKPL8FU
Phyton 35:
http://www.amazon.com/Phyton-Bactericide-fungicide-Substitute-Liter/dp/B00BGE65VM

Phyton 35 is announced as the "Substitute for Phyton 27" but I feel that
Phyton 27 is more tested and have a bigger user base.

Can you help to choose?

Best regards,
Roberto





___
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/rymg19%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/archive%40mail-archive.com

Re: [Python-Dev] Defining a path protocol (was: When should pathlib stop being provisional?)

[Ryan Gonzalez]

--
Ryan
[ERROR]: Your autotools build scripts are 200 lines longer than your
program. Something’s wrong.
http://kirbyfan64.github.io/
On Apr 6, 2016 12:28 PM, "Brett Cannon"  wrote:
>
> WIth Ethan volunteering to do the work to help make a path protocol a
thing -- and I'm willing to help along with propagating this through the
stdlib where I think Serhiy might be interested in helping as well -- and a
seeming consensus this is a good idea, it seems like this proposal has a
chance of actually coming to fruition.
>
> Now we need clear details. :) Some open questions are:

My votes:

> Name: __path__, __fspath__, or something else?

__path__. Considering everything related to `pathlib` uses the word `path`,
__fspath__ seems kind of odd.

> Method or attribute? (changes what kind of one-liner you might use in
libraries, but I think historically all protocols have been methods and the
serialized string representation might be costly to build)

Method. Using an attribute would be needlessly inconsistent.

> Built-in? (name is dependent on #1 if we add one)
> Add the method/attribute to str? (I assume so, much like __index__() is
on int, but I have not seen it explicitly stated so I would rather clarify
it)

I agree; this would avoid lots of excess complexity.

> Expand the C API to have something like PyObject_Path()?

-1. PyFileObject was already removed from Python 3; it seems useless to add
another one.

>
> Some people have asked for the pathlib PEP to have a more flushed out
reasoning as to why pathlib doesn't inherit from str. If Antoine doesn't
want to do it I can try to instil my blog post into a more succinct
paragraph or two and update the PEP myself.
>
> Is this going to require a PEP or if we can agree on the points here are
we just going to do it? If we think it requires a PEP I'm willing to write
it, but I obviously have no issue if we skip that step either. :)
>
> Oh, and we should resolve this before the next release of Python 3.4,
3.5, or 3.6 so that pathlib can be updated in those releases.
>
> -Brett
>
>
> On Wed, 6 Apr 2016 at 08:09 Ethan Furman  wrote:
>>
>> On 04/05/2016 11:57 PM, Nick Coghlan wrote:
>> > On 6 April 2016 at 16:53, Nathaniel Smith  wrote:
>> >> On Tue, Apr 5, 2016 at 11:29 PM, Nick Coghlan 
wrote:
>>
>> >>> I'd missed the existing precedent in DirEntry.path, so simply taking
>> >>> that and running with it sounds good to me.
>> >>
>> >> This makes me twitch slightly, because NumPy has had a whole set of
>> >> problems due to the ancient and minimally-considered decision to
>> >> assume a bunch of ad hoc non-namespaced method names fulfilled some
>> >> protocol -- like all .sum methods will have a signature that's
>> >> compatible with numpy's, and if an object has a .log method then
>> >> surely that computes the logarithm (what else in computing could "log"
>> >> possibly refer to?), etc. This experience may or may not be relevant,
>> >> I'm not sure -- sometimes these kinds of twitches are good guides to
>> >> intuition, and sometimes they are just knee-jerk responses to an old
>> >> and irrelevant problem :-)
>> >>
>> >> But you might want to at least think about
>> >> how common it might be to have existing objects with unrelated
>> >> attributes that happen to be called "path", and the bizarro problems
>> >> that might be caused if someone accidentally passes one of them to a
>> >> function that expects all .path attributes to be instances of this new
>> >> protocol.
>> >
>> > sys.path, for example.
>> >
>> > That's why I'd actually prefer the implicit conversion protocol to be
>> > the more explicitly named "__fspath__", with suitable "__fspath__ =
>> > path" assignments added to DirEntry and pathlib. However, I'm also not
>> > offering to actually *do* the work here, and the casting vote goes to
>> > the folks pursuing the implementation effort.
>>
>> If we decide upon __fspath__ (or __path__) I will do the work on pathlib
>> and scandir to add those attributes.
>
>
> ___
> 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/rymg19%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/archive%40mail-archive.com

Re: [Python-Dev] Wordcode: new regular bytecode using 16-bit units

[Ryan Gonzalez]

What is the value of HAS_ARG going to be now?

--
Ryan
[ERROR]: Your autotools build scripts are 200 lines longer than your
program. Something’s wrong.
http://kirbyfan64.github.io/
On Apr 13, 2016 11:26 AM, "Victor Stinner"  wrote:

> Hi,
>
> In the middle of recent discussions about Python performance, it was
> discussed to change the Python bytecode. Serhiy proposed to reuse
> MicroPython short bytecode to reduce the disk space and reduce the
> memory footprint.
>
> Demur Rumed proposes a different change to use a regular bytecode
> using 16-bit units: an instruction has always one 8-bit argument, it's
> zero if the instruction doesn't have an argument:
>
>http://bugs.python.org/issue26647
>
> According to benchmarks, it looks faster:
>
>   http://bugs.python.org/issue26647#msg263339
>
> IMHO it's a nice enhancement: it makes the code simpler. The most
> interesting change is made in Python/ceval.c:
>
> -if (HAS_ARG(opcode))
> -oparg = NEXTARG();
> +oparg = NEXTARG();
>
> This code is the very hot loop evaluating Python bytecode. I expect
> that removing a conditional branch here can reduce the CPU branch
> misprediction.
>
> I reviewed first versions of the change, and IMHO it's almost ready to
> be merged. But I would prefer to have a review from a least a second
> core reviewer.
>
> Can someone please review the change?
>
> --
>
> The side effect of wordcode is that arguments in 0..255 now uses 2
> bytes per instruction instead of 3, so it also reduce the size of
> bytecode for the most common case.
>
> Larger argument, 16-bit argument (0..65,535), now uses 4 bytes instead
> of 3. Arguments are supported up to 32-bit: 24-bit uses 3 units (6
> bytes), 32-bit uses 4 units (8 bytes). MAKE_FUNCTION uses 16-bit
> argument for keyword defaults and 24-bit argument for annotations.
> Other common instruction known to use large argument are jumps for
> bytecode longer than 256 bytes.
>
> --
>
> Right now, ceval.c still fetchs opcode and then oparg with two 8-bit
> instructions. Later, we can discuss if it would be possible to ensure
> that the bytecode is always aligned to 16-bit in memory to fetch the
> two bytes using a uint16_t* pointer.
>
> Maybe we can overallocate 1 byte in codeobject.c and align manually
> the memory block if needed. Or ceval.c should maybe copy the code if
> it's not aligned?
>
> Raymond Hettinger proposes something like that, but it looks like
> there are concerns about non-aligned memory accesses:
>
>http://bugs.python.org/issue25823
>
> The cost of non-aligned memory accesses depends on the CPU
> architecture, but it can raise a SIGBUS on some arch (MIPS and
> SPARC?).
>
> Victor
> ___
> Python-Dev mailing list
> Python-Dev@python.org
> https://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe:
> https://mail.python.org/mailman/options/python-dev/rymg19%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/archive%40mail-archive.com

Re: [Python-Dev] Wordcode: new regular bytecode using 16-bit units

[Ryan Gonzalez]

So code that depends on iterating through bytecode via HAS_ARG is going to
break...

Darn it. :/

--
Ryan
[ERROR]: Your autotools build scripts are 200 lines longer than your
program. Something’s wrong.
http://kirbyfan64.github.io/
On Apr 13, 2016 4:44 PM, "Victor Stinner"  wrote:

> Le mercredi 13 avril 2016, Ryan Gonzalez  a écrit :
>
>> What is the value of HAS_ARG going to be now?
>>
>
> I asked Demur to keep HAS_ARG(). Not really for backward compatibility,
> but for the dis module: to keep a nice assembler. There are also debug
> traces in ceval.c which use it.
>
> For ceval.c, we might use HAS_ARG() to micro-optimize oparg=0 (hardcode 0
> rather than reading the bytecode) for operators with no argument. Or maybe
> it's completly useless :-)
>
> Victor
>
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] support of the android platform

[Ryan Gonzalez]

Oh wow, has a year passed already? I don't have access to an Android device
suitable for development, and Cyd seems to have disappeared, which is why
the issue ended up abandoned. I'd be happy to try to help with the new
effort if possible!

--
Ryan
[ERROR]: Your autotools build scripts are 200 lines longer than your
program. Something’s wrong.
http://kirbyfan64.github.io/
On Apr 25, 2016 3:24 PM, "Xavier de Gaye"  wrote:

> On 04/25/2016 04:36 PM, Eric Snow wrote:
> > On Sun, Apr 24, 2016 at 1:20 AM, Xavier de Gaye 
> wrote:
> >> Starting with API level 21 (Android 5.0), the build of python3 with the
> >> official android toolchains (that is, without resorting to external
> >> libraries
> >> for wide character support) runs correctly.  With the set of patches
> >> described
> >> in the patches/Makefile file at [1], the cpython test suite runs[2] on
> the
> >> android x86 and armv7 emulators with only few errors[3].  Those errors
> are
> >> listed with their corresponding error messages, this may give a raw
> idea of
> >> the effort needed to support this platform.
> >
> > How does this relate to http://bugs.python.org/issue23496?
>
>
> The patches in issue 23496 address the native compilation of Android 4.4.2
> on
> an android device using a port of gcc on this device.  Some of these
> patches
> are not needed anymore on Android 5.0 and it seems that the kbox_fix.patch
> is
> needed because the KBOX application is used to build python in issue 23496.
>
> The existing issues that are relevant to the android platform are, I think:
> issue #26723: Add an option to skip _decimal module
> issue #22747: Interpreter fails in initialize on systems where
>   HAVE_LANGINFO_H is undefined
> issue #16353: add function to os module for getting path to default
> shell
> issue #20306: Lack of pw_gecos field in Android's struct passwd causes
>   cross-compilation for the pwd module to fail
>
> Xavier
>
> ___
> 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/rymg19%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/archive%40mail-archive.com

Re: [Python-Dev] Memory

[Ryan Gonzalez]

Well, I put this in Google Translate...and got this:

The disk clatters
the Spontie giggles
~
hopefully
alliance insures ...

Not sure if this a useless post or Translate just being weird. Leaning
towards the latter...

--
Ryan
[ERROR]: Your autotools build scripts are 200 lines longer than your
program. Something’s wrong.
http://kirbyfan64.github.io/
On May 1, 2016 3:48 AM, "Burkhard Meier"  wrote:

> ~
> Die Scheibe klirrt
> der Spontie kichert
> ~
> hoffentlich
> Alliiance versichert...
> ~
> https://youtu.be/m3SjCzA71eM
>
>
> ___
> 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/rymg19%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/archive%40mail-archive.com

Re: [Python-Dev] Need help in OCR implementation with Python3.5.1 or pyCharm Community edition

[Ryan Gonzalez]

On Thu, May 5, 2016 at 3:24 AM, Deepak Srivastava 
wrote:

>
> Dear All,
>
> I am new to python and very much excited to learn this technology.
>
> I have done setup of python 3.5.1 with PyCharm community edition on
> windows 7(64bit service pack 1).
>
> I am trying to execute some piece of code but it fails . Requesting you to
> please help.
>
>
>
> My Piece of code is
>
> *import *pytesseract
> *from *PIL *import *Image
> *from *PIL *import *ImageFilter
> *import *os
> print (os.getcwd())
> url=
> *"Polish.png"**def *process_image(*url*):
> image = _get_image(*url*)
> image = image.filter(ImageFilter.SHARPEN)
> #image = image.convert('1')
> print (pytesseract.image_to_string(image))
>
> *def *_get_image(*url*):
> *return *Image.open(*url*)
>
> process_image(url)
>
>
>
> Error which I am getting ,
>
> *C:\Users\Administrator\AppData\Local\Programs\Python\Python35-32\python.exe
> C:/Temp/Opt/src/ocr.py*
>
> *C:\Temp\Opt\src*
>
> *in subprocess*
>
> *None*
>
> *0*
>
> *None*
>
> *None*
>
> **
>
> *Traceback (most recent call last):*
>
> *  File "C:/Temp/Opt/src/ocr.py", line 17, in *
>
> *process_image(url)*
>
> *  File "C:/Temp/Opt/src/ocr.py", line 12, in process_image*
>
> *print (pytesseract.image_to_string(image))*
>
> *  File
> "C:\Users\Administrator\AppData\Roaming\Python\Python35\site-packages\pytesseract\pytesseract.py",
> line 161, in image_to_string*
>
> *config=config)*
>
> *  File
> "C:\Users\Administrator\AppData\Roaming\Python\Python35\site-packages\pytesseract\pytesseract.py",
> line 94, in run_tesseract*
>
> *stderr=subprocess.PIPE)*
>
> *  File
> "C:\Users\Administrator\AppData\Local\Programs\Python\Python35-32\lib\subprocess.py",
> line 950, in __init__*
>
> *restore_signals, start_new_session)*
>
> *  File
> "C:\Users\Administrator\AppData\Local\Programs\Python\Python35-32\lib\subprocess.py",
> line 1226, in _execute_child*
>
> *startupinfo)*
>
> *FileNotFoundError: [WinError 2] The system cannot find the file specified*
>
>
>
> *Process finished with exit code 1*
>
>
>
> Thanks and Regards
>
> Deepak Srivastava
>
>
>
>
Questions like this are better suited for python-list. Regardless, you need
to install Tesseract first:

https://github.com/tesseract-ocr/tesseract/wiki

That should fix the error.


>
> ___
> 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/rymg19%40gmail.com
>
>


-- 
Ryan
[ERROR]: Your autotools build scripts are 200 lines longer than your
program. Something’s wrong.
http://kirbyfan64.github.io/
___
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] Need help in OCR implementation with Python3.5.1 or pyCharm Community edition

[Ryan Gonzalez]

Well, the stack trace was pointing to the line that called Tesseract, so I
figured that was the problem.

--
Ryan
[ERROR]: Your autotools build scripts are 200 lines longer than your
program. Something’s wrong.
http://kirbyfan64.github.io/
On May 5, 2016 11:24 AM, "MRAB"  wrote:
>
> It looks to me that it's the url="Polish.png" that's the real cause of
the problem. It's not clear where the file "Polish.png" is actually stored.
It would be better to use a full file path.
>
>
> ___
> 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/rymg19%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/archive%40mail-archive.com

Re: [Python-Dev] runtime dlls on Windows

[Ryan Gonzalez]

Wouldn't downloading the Microsoft C++ Runtime 2015 also work? Many recent
computers already have it pre-installed.

--
Ryan
[ERROR]: Your autotools build scripts are 200 lines longer than your
program. Something’s wrong.
http://kirbyfan64.github.io/
On May 25, 2016 2:31 PM, "Chris Barker"  wrote:

> Hi folks,
>
> The standard build of Py3.5 for Windows is built with VS2015 (correct??)
> And it includes the runtime dlls it needs.
>
> However, we've found that wxPython wheels for win32 (not sure about win64)
> also need:
>
> MSVCP140.DLL
>
> So: wxPython could include that of course, But it looks like it's getting
> included with the Matplotlib wheels already (so folks with Matplotlib can
> run wx). I'm just guessing, but this looks like the standard run time
> for C++ with that compiler.
>
> Python itself doesn't use C++, of course, but maybe we should include that
> dll with Python anyway -- that way folks can build wheels of packages with
> C++ extensions  in the normal way, and those wheels will "just work", and
> we don't have to have every individual package ship the same dll.
>
> -CHB
>
>
> --
>
> Christopher Barker, Ph.D.
> Oceanographer
>
> Emergency Response Division
> NOAA/NOS/OR&R(206) 526-6959   voice
> 7600 Sand Point Way NE   (206) 526-6329   fax
> Seattle, WA  98115   (206) 526-6317   main reception
>
> chris.bar...@noaa.gov
>
> ___
> 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/rymg19%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/archive%40mail-archive.com

Re: [Python-Dev] New hash algorithms: SHA3, SHAKE, BLAKE2, truncated SHA512

[Ryan Gonzalez]

On May 27, 2016 3:04 PM, "Victor Stinner"  wrote:
>
> Le vendredi 27 mai 2016, M.-A. Lemburg  a écrit :
>>
>> The curent patch is 1.2MB for SHA-3 - that's pretty heavy for just
>>
>> a few hash functions, which aren't in any wide spread use yet and
>> probably won't be for quite a few years ahead.
>
>
> Oh wow, it's so fat? Why is it so big? Can't we use a lighter version?
>

The stark majority of the patch is Lib/test/vectors/sha3_224.txt, which
seems to be (as the file path implies) just test data. A whopping >1k LOC
of really long hashes.

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

--
Ryan
[ERROR]: Your autotools build scripts are 200 lines longer than your
program. Something’s wrong.
http://kirbyfan64.github.io/
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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

[Ryan Gonzalez]

Just don't run it on Windows...


On Tue, Dec 3, 2013 at 10:25 AM, Guido van Rossum  wrote:

> I would be rather worried about some accidental Trojen running that way.
>
> ___
> 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/rymg19%40gmail.com
>
>


-- 
Ryan
When your hammer is C++, everything begins to look like a thumb.
___
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] Migration from Python 2.7 and bytes formatting

[Ryan Gonzalez]

A command line parameter??

The annoying part would be telling every single user to call Python with a
certain argument and hope they read the README.

If it's a library, out of the question.

If it's a program, well, I hope your users read READMEs.


On Fri, Jan 17, 2014 at 4:49 AM, Neil Schemenauer  wrote:

> As I see it, there are two separate goals in adding formatting
> methods to bytes.  One is to make it easier to write new programs
> that manipulate byte data.  Another is to make it easier to upgrade
> Python 2.x programs to Python 3.x.  Here is an idea to better
> address these separate goals.
>
> Introduce %-interpolation for bytes.  Support the following format
> codes to aid in writing new code:
>
> %b: insert arbitrary bytes (via __bytes__ or Py_buffer)
>
> %[dox]: insert an integer, encoded as ASCII
>
> %[eEfFgG]: insert a float, encoded as ASCII
>
> %a: call ascii(), insert result
>
> Add a command-line option, disabled by default, that enables the
> following format codes:
>
> %s: if the object has __bytes__ or Py_buffer then insert it.
> Otherwise, call str() and encode with the 'ascii' codec
>
> %r: call repr(), encode with the 'ascii' codec
>
> %[iuX]: as per Python 2.x, for backwards compatibility
>
> Introducing these extra codes and the command-line option will
> provide a more gradual upgrade path.  The next step in porting could
> be to examine each %s inside bytes literals and decide if they
> should either be converted to %b or if the literal should be
> converted to a unicode literal.  Any %r codes could likely be safely
> changed to %a.
>
> ___
> 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/rymg19%40gmail.com
>



-- 
Ryan
When your hammer is C++, everything begins to look like a thumb.
___
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] Migration from Python 2.7 and bytes formatting

[Ryan Gonzalez]

Regardless, I still feel the introduction of a switch and all that stuff is
too complicated. I understand you position, since all my applications are
written in Python 2(except 1). However, I don't think this is the best
solution.


On Fri, Jan 17, 2014 at 2:19 PM, Neil Schemenauer  wrote:

> On 2014-01-17, Ryan Gonzalez wrote:
> > A command line parameter??
>
> I believe it has to be global flag.  A __future__ statement will not
> work.  Probably we should allow the flag to be set with an
> environment variable as well.
>
> > The annoying part would be telling every single user to call Python with
> a
> > certain argument and hope they read the README.
> >
> > If it's a library, out of the question.
> >
> > If it's a program, well, I hope your users read READMEs.
>
> The purpose of the command line parameter is not for end users.  It
> is intended to help developers port millions of lines of existing
> Python 2.x code.  I'm very sad if Python core developers don't
> realize the enormity of the task and don't continue to make efforts
> to make it easier.
>
> Regards,
>
>   Neil
>



-- 
Ryan
When your hammer is C++, everything begins to look like a thumb.
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] str.rreplace

[Ryan Gonzalez]

http://stackoverflow.com/questions/2556108/how-to-replace-the-last-occurence-of-an-expression-in-a-string



On Fri, Jan 24, 2014 at 10:32 AM, Ram Rachum  wrote:

> Question: Why is there no str.rreplace in Python?
>
> ___
> 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/rymg19%40gmail.com
>
>


-- 
Ryan
If anybody ever asks me why I prefer C++ to C, my answer will be simple:
"It's becauseslejfp23(@#Q*(E*EIdc-SEGFAULT. Wait, I don't think that was
nul-terminated."
___
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 3.4: Cherry-picking into rc2 and final

[Ryan Gonzalez]

Sounds like you aren't exactly a DVCS fan...


On Tue, Feb 18, 2014 at 8:46 PM, Guido van Rossum  wrote:

> I do think there's one legitimate concern -- someone might pull a diff
> from Larry's branch and then accidentally push it back to the public repo,
> and then Larry would be in trouble if he was planning to rebase that diff.
> (The joys of DVCS -- we never had this problem in the cvs or svn days...)
>
> Publishing tarballs would prevent this and still let people test the exact
> code Larry is assembling on their favorite obscure platform.
>
>
> On Tue, Feb 18, 2014 at 3:54 PM, Barry Warsaw  wrote:
>
>> On Feb 19, 2014, at 12:38 AM, Matthias Klose wrote:
>>
>> >Am 17.02.2014 00:25, schrieb Larry Hastings:
>> >> And my local branch will remain private until 3.4.0 final ships!
>> >
>> >sorry, but this is so wrong. Is there *any* reason why to keep this
>> branch
>> >private?
>>
>> IMO, no.  read-only for !larry sure, but not private.
>>
>> -Barry
>>
>> ___
>> 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/guido%40python.org
>>
>
>
>
> --
> --Guido van Rossum (python.org/~guido)
>
> ___
> Python-Dev mailing list
> Python-Dev@python.org
> https://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe:
> https://mail.python.org/mailman/options/python-dev/rymg19%40gmail.com
>
>


-- 
Ryan
If anybody ever asks me why I prefer C++ to C, my answer will be simple:
"It's becauseslejfp23(@#Q*(E*EIdc-SEGFAULT. Wait, I don't think that was
nul-terminated."
___
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] Poll: Py_REPLACE/Py_ASSIGN/etc

[Ryan Gonzalez]

I like Py_DECREF_REPLACE. It gives the impression that it decrefs the
original and replaces it.


On Wed, Feb 26, 2014 at 3:40 AM, Serhiy Storchaka wrote:

> There were several suggestions for naming new macros which replace old
> value with new value and then (x)decref old value.
>
> #define Py_XXX(ptr, value)\
> { \
> PyObject *__tmp__ = ptr;  \
> ptr = new_value;  \
> Py_DECREF(__tmp__);   \
> }
>
> Listed in order of receipt:
>
> 1. Py_(X)SETREF.
> 2. Py_(X)ASSIGN.
> 3. Py_(X)DECREC_REPLACE.
> 4. Py_REF_ASSIGN (Py_XREF_ASSIGN? Py_REF_XASSIGN?).
> 5. Py_(X)REPLACE.
> 6. Py_(X)STORE
> 7. Py_CLEAR_AND_SET.
> 8. Py_SET_AND_(X)DECREF.
> 9. Py_(X)DECREF_AND_ASSIGN.
> 10. Py_ASSIGN_AND_(X)DECREF.
> 11. Other...
>
> Let's choose the least confusing names.
>
> See discussions at:
>
> http://bugs.python.org/issue3081
> http://bugs.python.org/issue16447
> http://bugs.python.org/issue20440
> http://comments.gmane.org/gmane.comp.python.devel/145346
>
> ___
> 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/
> rymg19%40gmail.com
>



-- 
Ryan
If anybody ever asks me why I prefer C++ to C, my answer will be simple:
"It's becauseslejfp23(@#Q*(E*EIdc-SEGFAULT. Wait, I don't think that was
nul-terminated."
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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

[Ryan Gonzalez]

You forgot 3., and 3.$.


On Mon, Mar 10, 2014 at 12:06 PM, Chris Angelico  wrote:

> On Tue, Mar 11, 2014 at 3:56 AM, Antoine Pitrou 
> wrote:
> > On Mon, 10 Mar 2014 17:04:08 +0100
> > "Stefan Richthofer"  wrote:
> >
> >> > Guido famously hates two digit minor version numbers. :)
> >>
> >> This is no problem either. Simply switch to hexadecimal numbering ;)
> >
> > Or wrap around to negative numbers (a minus sign isn't technically a
> > digit, is it?).
>
> Terrible idea. Would wreak havoc with comparisons. No. Python 3 is all
> about Unicode, so the right way to proceed is 3.8, 3.9, 3.:, 3.;, 3.<,
> 3.=, 3.>, 3.?, 3.@, 3.A.
>
> ChrisA
> ___
> 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/rymg19%40gmail.com
>



-- 
Ryan
If anybody ever asks me why I prefer C++ to C, my answer will be simple:
"It's becauseslejfp23(@#Q*(E*EIdc-SEGFAULT. Wait, I don't think that was
nul-terminated."
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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

[Ryan Gonzalez]

This is my standpoint. The major releases would remove the code that's been
marked as "deprecated". You probably would've know for the past 3 versions
anyway...


On Mon, Mar 10, 2014 at 12:13 PM, Chris Angelico  wrote:

> On Tue, Mar 11, 2014 at 4:08 AM, R. David Murray 
> wrote:
> >  (That said, I
> > do see some merit to doing some extra cleaning at the 4.0
> > boundary, just for mental convenience.)
>
> A transition from 3.9 to 4.0 that removes a whole lot of deprecated
> aliases and such wouldn't be a bad thing. It's technically breaking
> backward compat (and thus justifying the major version bump), but any
> code broken by it would have been unidiomatic for the past X versions
> anyway.
>
> ChrisA
> ___
> 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/rymg19%40gmail.com
>



-- 
Ryan
If anybody ever asks me why I prefer C++ to C, my answer will be simple:
"It's becauseslejfp23(@#Q*(E*EIdc-SEGFAULT. Wait, I don't think that was
nul-terminated."
___
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] [RELEASED] Python 3.4.0

[Ryan Gonzalez]

YES!!! +1 to the authors of the statistics and pathlib modules.


On Mon, Mar 17, 2014 at 1:29 AM, Larry Hastings  wrote:

>
> On behalf of the Python development team, I'm thrilled to announce
> the official release of Python 3.4.
>
>
> Python 3.4 includes a range of improvements of the 3.x series, including
> hundreds of small improvements and bug fixes.  Major new features and
> changes in the 3.4 release series include:
>
> * PEP 428, a "pathlib" module providing object-oriented filesystem paths
> * PEP 435, a standardized "enum" module
> * PEP 436, a build enhancement that will help generate introspection
>information for builtins
> * PEP 442, improved semantics for object finalization
> * PEP 443, adding single-dispatch generic functions to the standard library
> * PEP 445, a new C API for implementing custom memory allocators
> * PEP 446, changing file descriptors to not be inherited by default
>in subprocesses
> * PEP 450, a new "statistics" module
> * PEP 451, standardizing module metadata for Python's module import system
> * PEP 453, a bundled installer for the *pip* package manager
> * PEP 454, a new "tracemalloc" module for tracing Python memory allocations
> * PEP 456, a new hash algorithm for Python strings and binary data
> * PEP 3154, a new and improved protocol for pickled objects
> * PEP 3156, a new "asyncio" module, a new framework for asynchronous I/O
>
>
> To download Python 3.4.0 visit:
>
> http://www.python.org/download/releases/3.4.0/
>
>
> This is a production release.  Please report any issues you notice to:
>
>  http://bugs.python.org/
>
>
> Enjoy!
>
>
> --
> Larry Hastings, Release Manager
> larry at hastings.org
> (on behalf of the entire python-dev team and 3.4's contributors)
> ___
> 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/
> rymg19%40gmail.com
>



-- 
Ryan
If anybody ever asks me why I prefer C++ to C, my answer will be simple:
"It's becauseslejfp23(@#Q*(E*EIdc-SEGFAULT. Wait, I don't think that was
nul-terminated."
___
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] issue with itertools leads the crash

[Ryan Gonzalez]

2015!?!? I was hoping it was a tad further off...the PyPy team is going to
have to start freaking out in about 12 months.


On Wed, Apr 9, 2014 at 8:26 AM, Mark Lawrence wrote:

> On 08/04/2014 17:30, MRAB wrote:
>
>> On 2014-04-08 16:31, Brett Cannon wrote:
>>
>> Something for Python 3.5, maybe? :-)
>>
>> It's not going to happen in Python 2.7; that's the end of the Python 2
>> series, and it's getting security fixes only.
>>
>
> According to http://legacy.python.org/dev/peps/pep-0373/ the final
> release of 2.7 is scheduled to be 2.7.9 in May 2015.  Did you mean to say
> that 2.7 isn't getting new features?
>
> --
> My fellow Pythonistas, ask not what our language can do for you, ask what
> you can do for our language.
>
> Mark Lawrence
>
> ---
> This email is free from viruses and malware because avast! Antivirus
> protection is active.
> http://www.avast.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/
> rymg19%40gmail.com
>



-- 
Ryan
If anybody ever asks me why I prefer C++ to C, my answer will be simple:
"It's becauseslejfp23(@#Q*(E*EIdc-SEGFAULT. Wait, I don't think that was
nul-terminated."
___
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] Language Summit notes

[Ryan Gonzalez]

On Thu, Apr 10, 2014 at 3:12 PM, Paul Moore  wrote:

> On 10 April 2014 20:30, Antoine Pitrou  wrote:
> > FWIW, I do hope there would be a PEP before including CFFI... Actually I
> > don't understand what would justify an exemption.
>
> I agree. I'd like to see a clear explanation of what advantages (and
> disadvantages!) CFFI gives over ctypes, as well as the plan for
> inclusion and how the inevitable confusion over whether to use ctypes
> or cffi will be handled. The fact that cffi requires bringing in ply
> and a vendored-but-not-public copy of pycparser, seems to imply to me
> that there's a lot of cost and I'd like to understand the gains.
> That's not to say that adding ply to the standard library mightn't be
> worth it in its own right, but there are a lot of other parsers out
> there, and I'd rather we blessed one as "best of breed" rather than
> "because cffi uses it".
>
> In particular, my understanding is that in order to get the key
> benefits of cffi (API compatibility rather than ABI) you need to
> include some sort of complex "generate and compile C" step in your
> project's build. That implies that using cffi requires building
> separate wheels for each Python version (as with any C extension) and
> having a C compiler to do the build. There are a lot of projects that
> I know of (particularly wrappers for Windows APIs like Colorama and
> pyreadline) migrating to ctypes precisely because they get a pure
> Python solution that doesn't need binary builds or version-dependent
> distributions. Those projects won't presumably be migrating to cffi.
> Also, a key area where ctypes is used seems to be the Windows API -
> and there, ABI compatibility for Windows APIs is the norm so the
> advantage of only needing API compatibility is minimal at best.
>

Nope. CFFI supports both C-built extensions and ctypes-style shared library
loading. There are pure-Python bindings for modules that use CFFI and don't
require a C compiler(https://github.com/kirbyfan64/clamav-python).


> At the moment, I see no real reason to add cffi to the stdlib - it
> certainly isn't an "obvious" decision to do so. This seems like clear
> PEP territory.


It's somewhat faster but has a longer warm-up time. Useful if the same
module is going to be reused several times.


>
> Paul
> ___
> 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/rymg19%40gmail.com
>



-- 
Ryan
If anybody ever asks me why I prefer C++ to C, my answer will be simple:
"It's becauseslejfp23(@#Q*(E*EIdc-SEGFAULT. Wait, I don't think that was
nul-terminated."
___
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 "2migr8"

[Ryan Gonzalez]

On Mon, Apr 14, 2014 at 9:03 PM, Chris Angelico  wrote:

> On Tue, Apr 15, 2014 at 7:17 AM, Chris Barker 
> wrote:
> > On Mon, Apr 14, 2014 at 1:26 PM, Guido van Rossum 
> wrote:
> >
> >>
> >> >> - I'd prefer a name that plays on 2 and 3, not 2 and 8. :-)
> >
> > How about mirg2**3 (pronounced "migrate") ?
> >
> > ;-)
> >
>
> Just read this, and laughed so loudly and suddenly that my brother's
> cat jumped in fright.
>
> Spelled 2**3 and pronounced 8 makes perfect sense, same as spelling
> "Mercurial" as "hg".
>

...unless the reader doesn't know math. That would be
funny...*migrtoostarstarthree*


>
> ChrisA
> ___
> 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/rymg19%40gmail.com
>



-- 
Ryan
If anybody ever asks me why I prefer C++ to C, my answer will be simple:
"It's becauseslejfp23(@#Q*(E*EIdc-SEGFAULT. Wait, I don't think that was
nul-terminated."
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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

[Ryan Gonzalez]

SHELLS ARE NOT CROSS-PLATFORM Seriously, there are going to be
differences. If you really must:

escape = lambda s: s.replace('^', '^^') if os.name == 'nt' else s

Viola.



On Wed, Jun 11, 2014 at 5:53 PM, anatoly techtonik 
wrote:

> On Thu, Jun 12, 2014 at 1:30 AM, Chris Angelico  wrote:
>
>> On Thu, Jun 12, 2014 at 7:58 AM, Ryan  wrote:
>> > In all seriousness, to me this is obvious. When you pass a command to
>> the
>> > shell, naturally, certain details are shell-specific.
>>
>
> On Windows cmd.exe is used by default:
> http://hg.python.org/cpython/file/38a325c84564/Lib/subprocess.py#l1108
> so it makes sense to make default behavior cross-platform.
>
>
>>  > -1. Bad idea. Very bad idea. If you want the ^ to be escaped, do it
>> > yourself. Or better yet, don't pass shell=True.
>>
>> Definitely the latter. Why pass shell=True when executing a single
>> command? I don't get it.
>>
>
> This is a complete use case using Rietveld upload script:
>
> http://techtonik.rainforce.org/2013/07/code-review-with-rietveld-and-mercurial.html
>
> I am interested to know how to modify upload script without kludges:
> https://code.google.com/p/rietveld/source/browse/upload.py#1056
> I expect many people are facing with the same problem trying to wrap
> Git and HG with Python scripts.
> --
> anatoly t.
>
> ___
> 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/rymg19%40gmail.com
>
>


-- 
Ryan
If anybody ever asks me why I prefer C++ to C, my answer will be simple:
"It's becauseslejfp23(@#Q*(E*EIdc-SEGFAULT. Wait, I don't think that was
nul-terminated."
___
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