[Python-Dev] Re: [std-proposals] Exception compatibility with aliens

[Barry Scott]

> On 18 Jan 2023, at 15:35, Frederick Virchanza Gotham 
>  wrote:
> 
> On Wed, Jan 18, 2023 at 3:07 PM Jason McKesson wrote:
>> 
>> Also, this proposal seems to be missing the biggest issue with
>> cross-language exception handling: the fact that you can't throw
>> exceptions across languages. The only thing you *can* do is catch
>> exceptions on the source language end, convert them into some data
>> packet, and throw a different exception on the destination language
>> side.
> 
> 
> Yes this is what I had in mind. Behind the scenes, the C++ compiler
> would catch the Python exception and then throw something that C++ can
> deal with "such as std::aliens::python::exception".

In PyCXX I allows exceptions to go into and out of python and C++.
https://cxx.sourceforge.net/

You can raise in C++ go into python and back into C++ and the exception arrives 
as expected.
You can riase in Python fo into C++ and back to Python and again the exception 
arrives as expected.
 That is as long as its a python exception.

Barry

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

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

[Python-Dev] Re: Switching to Discourse

[Barry Scott]

> On 11 Dec 2022, at 21:05, Abdur-Rahmaan Janhangeer  
> wrote:
> 
> If only, fellow list colleagues, I could see only the topics I choose on 
> Discourse.

Have you tried changing the Preferences for Notifications/Categories?
That would appear to give you the control you are asking for?

Barry

> 
> The Discourse feels like python-list, python-dev, python-* combined. 
> I feel cluttered. 
> 
> If only I could also export the folks using only the mailing list to the 
> Discourse.
> 
> If only Discourse was as easy to search and port as a mail archive.
> 
> If Python is a community thing, the discourse is it. But, I fear, crafting 
> mail
> and reading walls of text might become the skills of a bygone age.
> 
> On Discourse i miss the simplicity of a medialess, interactionless, botless, 
> privilegeless,
> notificationless, badgeless platform.
> 
> But, we must keep up with advances in tech, cope with different ways, cope 
> with
> what most people use. It's the way forward. 
> 
> Next time, see you at PythonHut in the Metaverse.
> 
> Kind Regards,
> 
> Abdur-Rahmaan Janhangeer
> about  | blog 
>  
> github 
> Mauritius
> ___
> Python-Dev mailing list -- python-dev@python.org
> To unsubscribe send an email to python-dev-le...@python.org
> https://mail.python.org/mailman3/lists/python-dev.python.org/
> Message archived at 
> https://mail.python.org/archives/list/python-dev@python.org/message/JA76LADBRCVDOGPBVCAXPM66QKDBODU7/
> Code of Conduct: http://python.org/psf/codeofconduct/

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

[Python-Dev] Re: Adding new escapes to regex module

[Barry Scott]

> On 16 Aug 2022, at 21:24, MRAB  wrote:
> 
> Other regex implementations have escape sequences for horizontal whitespace 
> (`\h` and `\H`) and vertical whitespace (`\v` and `\V`).
> 
> The regex module already supports `\h`, but I can't use `\v` because it 
> represents `\0x0b', as it does in the re module.

You seem to be mixing the use \ as the escape for strings and the \ that re 
uses.
Is it the behaviour that '\' becomes '\\' that means this is 
a breaking change?

Won't this work?
```
re.compile('\v:\\v')
# which is the same as
re.compile(r'\x0b:\v')
```

Barry

> Now that someone has asked for it, I'm trying to find a nice way of adding 
> it, and I'm currently thinking that maybe I could use `\y` and `\Y` instead 
> as they look a little like `\v` and `\V`, and, also, vertical whitespace is 
> sort-of in the y-direction.
> 
> As far as I can tell, only ProgressSQL uses them, and, even then, it's for 
> what everyone else writes as `\b` and `\B`.
> 
> I want the regex module to remain compatible with the re module, in case they 
> get added there sometime in the future.
> 
> Opinions?
> ___
> Python-Dev mailing list -- python-dev@python.org
> To unsubscribe send an email to python-dev-le...@python.org
> https://mail.python.org/mailman3/lists/python-dev.python.org/
> Message archived at 
> https://mail.python.org/archives/list/python-dev@python.org/message/AYOYEAFOJW4ZHVYBDVMH4MWKXNLBBJ62/
> Code of Conduct: http://python.org/psf/codeofconduct/
> 

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

[Python-Dev] Re: Deadlock when interrupting interpreter initialisation with ptrace?

[Barry Scott]

> On 6 Jun 2022, at 17:52, Gabriele  wrote:
> 
> I've found it hard to give an answer to this question. Because austinp
> is already tracing the interpreter, I cannot use, e.g., gdb to dump a
> backtrace.


Don't you have the backtrace from libunwind that you could save from austinp 
itself?

Barry

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

[Python-Dev] Re: Add -P command line option to not add sys.path[0]

[Barry Scott]

> On 27 Apr 2022, at 20:21, Miro Hrončok  wrote:
> 
> On 27. 04. 22 20:45, Barry wrote:
>>> On 27 Apr 2022, at 17:22, Victor Stinner  wrote:
>>> 
>>> Ok, you changed my mind and I added PYTHONDONTADDPATH0=1 env var. Example:
>> Maybe the env var say what it is not adding rather then where it adds it.
>> PYTHONDONTADDPWD=1
> 
> But it is not "just" the PWD. In the case of shebangs, it's actually the 
> script's directory. E.g. a script in /usr/bin/ normally has /usr/bin/ in 
> sys.path (which is not desired, hence we (Fedora) would probably add the -P 
> flag to default shebangs for programs in /usr/bin/).

naming is so hard... may do "don't add implicit dirs"?

PYTHONDONTADDIMPLICTDIRS=1

(I wish there where _ to show the word boundaries, but that ship has sailed)

Barry

> 
> -- 
> Miro Hrončok
> -- 
> Phone: +420777974800
> IRC: mhroncok
> 

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

[Python-Dev] Re: Need Help

[Barry Scott]

> On 25 Feb 2022, at 12:58, Prasad, PCRaghavendra 
>  wrote:
> 
> Hi All,
> 
> we are using the python 3.9.5 version in our application.
>  
> In 3.9.5 it is using libexpat 2.2.8 version, as part of the Black duck scan, 
> it is showing critical vulnerabilities in libexpat 2.2.8.
>  
> (CVE-2022-22824
> CVE-2022-23990
> CVE-2022-23852
> CVE-2022-25236
> CVE-2022-22823)
> 
> when there are any issues ( security issues ) in external modules like 
> OpenSSL, bzip2, and zlib we were able to get the latest code and build as it 
> is straightforward, but libexpat is an internal module to the python and we 
> don't see how we can upgrade libexpat alone in python 3.9.5
> 
> So is there a way we can build python (ex 3.9.5) which is already carrying 
> libexpat 2.2.8 so that it will link to the latest libexpat version (2.4.6 - 
> fixed security issues).
> 
> Another solution when we searched over the net and from the mails what we 
> came to know is we need to wait for Python 3.9.11 where this will be linked 
> to libexpat 2.4.6.
> 
> Any inputs on this will be helpful.

Are you asking how to link python to an external libexpat instead of the 
vendored expat inside python?

Have you tried deleting libexpat 2.2.8 from the python source code and 
replacing with the libexpat 2.4.6 and then
compiling python?

Are you concerned that you need fixes in the python code to support the 2.4 
version?

Barry


> 
> Thanks,
> Raghu
> 
> Internal Use - Confidential
> ___
> Python-Dev mailing list -- python-dev@python.org 
> 
> To unsubscribe send an email to python-dev-le...@python.org 
> 
> https://mail.python.org/mailman3/lists/python-dev.python.org/ 
> 
> Message archived at 
> https://mail.python.org/archives/list/python-dev@python.org/message/2JHZTKQVVYR67KQRIFF5XEMXDY3FZLMN/
>  
> 
> Code of Conduct: http://python.org/psf/codeofconduct/ 
> 
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/GSI2MC5VGPU24SOZIDINGBCOD3NFM5S4/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: 3.11 enhanced error location - can it be smarter?

[Barry Scott]

> On 20 Jan 2022, at 02:22, Skip Montanaro  wrote:
> 
> (This really belongs on python-ideas, right?)
> 

I'm commenting on the implementation that is on going. python-ideas does not 
seem right.

Barry

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

[Python-Dev] Re: 3.11 enhanced error location - can it be smarter?

[Barry Scott]

> On 19 Jan 2022, at 21:19, Ethan Furman  wrote:
> 
> An environment variable would solve this, yes?  The default would be using 
> the underlining carets, but an env var could switch that to using color 
> instead.

Oh and if you use colours then you please give me the ability to set the 
colours for each usage.

I have custom colour settings for a lots of unix tools so that I get contrast 
etc.
The defaults used may only work in light mode and be unusable dark mode for 
example.

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

[Python-Dev] Re: 3.11 enhanced error location - can it be smarter?

[Barry Scott]

> On 19 Jan 2022, at 21:19, Ethan Furman  wrote:
> 
> On 1/19/22 1:10 PM, Barry Scott wrote:
> > On 18 Jan 2022, at 19:59, Pablo Galindo Salgado wrote:
> 
> >> We considered using colours and other markers such as bold text, but that 
> >> opens a considerable can of worms with
> >> detecting in all systems and configurations if that can be done. I have 
> >> been told that some of these situations are
> >> quite tricky and is not as easy as checking for tty support.
> >>
> >
> > In the apps I work on as open source and paid work tracebacks are put into 
> > log files so that
> > we can fix the rare bugs. It would not be nice if the traceback module API 
> > started providing
> > text with embedded escape sequences without a way to turn then off in the 
> > API.
> 
> An environment variable would solve this, yes?  The default would be using 
> the underlining carets, but an env var could switch that to using color 
> instead.

I have no objection to use of an env var as the default at python startup.
But not as the only way to set a feature. I find it a poor API.

Give me a set/get API and I can design my app to behave in a suitable
way for its use.

It means that I cannot have all the logic of the app in the python sources.

Barry

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

[Python-Dev] Re: 3.11 enhanced error location - can it be smarter?

[Barry Scott]

> On 18 Jan 2022, at 19:59, Pablo Galindo Salgado  wrote:
> 
> We considered using colours and other markers such as bold text, but that 
> opens a considerable can of worms with detecting in all systems and 
> configurations if that can be done. I have been told that some of these 
> situations are quite tricky and is not as easy as checking for tty support.
> 

In the apps I work on as open source and paid work tracebacks are put into log 
files so that
we can fix the rare bugs. It would not be nice if the traceback module API 
started providing
text with embedded escape sequences without a way to turn then off in the API.

On the other hand it would be great to be able, as an API call, to set the 
style of the traceback
text.

Barry

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

[Python-Dev] Re: Is anyone using 15-bit PyLong digits (PYLONG_BITS_IN_DIGIT=15)?

[Barry Scott]

> On 17 Jan 2022, at 06:35, Tim Peters  wrote:
> 
> [Guido]
>> I don't think there's a way to do a PGO build from Visual Studio; but
>> a command prompt in the repo can do it using `PCbuild\build.bat --pgo`.
>> Just be patient with it.
> 
> Thanks! That worked, and was easy, and gave me an executable that runs
> "// 10" at supernatural speed.
> 
> Alas, Visual Studio will not show a disassembly window unless the
> debugger is running, and there appears to be no way to convince it to
> run its debugger without it first recompiling the source file you're
> staring at. Which it recomplies without benefit of PGO.

The trick you need is to close the project you use to build python
from source then you can open the python.exe and run that under the
debugger. Because it can find the python.pdb it will source/disasm as
you want. 

Barry


> 
> So, in the end, it was an elaborate way to reproduce the ;non-PGO
> optimized machine code I already saw :-)
> ___
> Python-Dev mailing list -- python-dev@python.org
> To unsubscribe send an email to python-dev-le...@python.org
> https://mail.python.org/mailman3/lists/python-dev.python.org/
> Message archived at 
> https://mail.python.org/archives/list/python-dev@python.org/message/D47HHYYASRHS56AZL6SEK4Y7K5FNSJOP/
> Code of Conduct: http://python.org/psf/codeofconduct/
> 

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

[Python-Dev] Re: Function Prototypes

[Barry Scott]

> On 26 Dec 2021, at 02:16, Steven D'Aprano  wrote:
> 
>> Hard enough that you really ought to help your reader out with a 
>> name,
> 
> What are you going to name it?
> 
>Int_and_Float_and_Int_returns_List_of_Int_Function
> 
> tells us nothing that
> 
>(int, float, int) -> list[int]
> 
>Callable[[int, float, int], list[int]]
> 
> doesn't already say.

It was said earlier in this thread that the naming should depend in the problem 
domain.

That name will not be as you suggest a long wordy thing but have a
name that is easier to understand.

So it might be CostFunction that would be a great name in that problem domain.

Barry

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

[Python-Dev] Re: PEP 654 except* formatting

[Barry Scott]

> On 6 Oct 2021, at 18:48, Guido van Rossum  wrote:
> 
> On Wed, Oct 6, 2021 at 9:01 AM Brandt Bucher  > wrote:
> Another option (to remove the ambiguity) could be to move the “group” after 
> the expression. Bonus points for reading more clearly:
> 
> except MemoryError group as e: …
> except (KeyError, IndexError) group as e: …
> except some + expression group as e: …
> 
> Argh. This would be very easy to overlook. As the senior author of PEP 654 I 
> am going to go with "except*". Since it was shown that "except group" has 
> ambiguous edge cases the proposals have gotten worse, which to me is a good 
> sign that we need to stop.

With async it goes *before* def, for, with.
Can you put the group before the except in the same style?

try:
stuff...
group except :
handler...

Barry


> 
> -- 
> --Guido van Rossum (python.org/~guido )
> Pronouns: he/him (why is my pronoun here?) 
> ___
> Python-Dev mailing list -- python-dev@python.org
> To unsubscribe send an email to python-dev-le...@python.org
> https://mail.python.org/mailman3/lists/python-dev.python.org/
> Message archived at 
> https://mail.python.org/archives/list/python-dev@python.org/message/RRHP6VRI5PUMRSIXKFQVR2E6L523NUVC/
> Code of Conduct: http://python.org/psf/codeofconduct/

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

[Python-Dev] Re: PEP 467 feedback from the Steering Council

[Barry Scott]

> On 8 Sep 2021, at 06:39, Steven D'Aprano  wrote:
> 
> On Tue, Sep 07, 2021 at 08:09:33PM -0700, Barry Warsaw wrote:
> 
>> I think Nick is on board with bytes.fromint() and no bchr(), and my 
>> sense of the sentiment here is that this would be an acceptable 
>> resolution for most folks.  Ethan, can you reconsider?
> 
> I haven't been completely keeping up with the entire thread, so 
> apologies if this has already been covered. I assume that the idea is 
> that bytes.fromint should return a single byte, equivalent to chr() 
> returning a single character.
> 
> To me, it sounds like should be the opposite of int.from_bytes.
> 
 int.from_bytes(b'Hello world', 'little')
>121404708502361365413651784
 bytes.from_int(121404708502361365413651784, 'little')
># should return b'Hello world'

:>>> int.from_bytes(b'\x00\x00\x00\x01', byteorder='big')
1
:>>> bytes.from_int(1)
would return b'\x01'? Without a length it cannot return b'\x00\x00\x00\x01'

Barry

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

[Python-Dev] Re: Weird io.OpenWrapper hack to use a function as method

[Barry Scott]

> On 31 Mar 2021, at 13:34, Victor Stinner  wrote:
> 
> def func():
>print("my func")


This would work for the example given of a func with no args.
But cannot check it called with the right number.

def func(*args):
   print("my func")

A signature like this would be a hard nut to crack.

def func(fixed, *args):
print("my func", fixed, args)

Barry

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

[Python-Dev] Re: PEP 654 -- Exception Groups and except* : request for feedback for SC submission

[Barry Scott]

> On 23 Feb 2021, at 00:24, Irit Katriel via Python-Dev  
> wrote:
> 
> 
> Hi all,
> 
> We would like to request feedback on PEP 654 -- Exception Groups and except*.
> 
> https://www.python.org/dev/peps/pep-0654/ 
> 
> 
> It proposes language extensions that allow programs to raise and handle 
> multiple unrelated
> exceptions simultaneously, motivated by the needs of asyncio and other 
> concurrency libraries,
> but with other use cases as well.
> 
> * A new standard exception type,  ExceptionGroup, to represent multiple 
> exceptions with
>   shared traceback.
> * Updates to the traceback printing code to display (possibly nested) 
> ExceptionGroups.
> * A new syntax except* for handling ExceptionGroups.
> 
> A reference implementation (unreviewed) can be found at:
> https://github.com/iritkatriel/cpython/pull/10 
> 
Have you considered alternative syntax to the "except*"?
I feel that expect* is too easy to confuse with plain except.

As others have said needing to change all except Exception:
handlers would be a breaking change for code that I maintain.

I think its accepted that that idiom should continue to be as
reliable as it currently is. Can you confirm that I have understood
the conversation on this point?

I have been thinking about why I would be getting an ExceptionGroup
with, for example, a number of OSError for a handler to deal with.
Would it not be a difficult piece of code to write without the context of
each OSError?

What I'm think is that the lower level pieces would be catching the OSError
closer to the source of the problem and raising a App/Lib specific exception
that provides the context. For example AppFailedToSaveConfigError and
AppFailedToSaveDataError as oppose to a two permission OSError's.

With context I can imagine that handling the ExceptionGroup would be
a lot easier for the App designer.

If that the pattern that emerges then is the complexity of nested
ExceptionGroups going to only rarely used?

Barry


> 
> Thank you for your help
> 
> Kind regards
> Irit, Yury & Guido
> 
> 
> ___
> Python-Dev mailing list -- python-dev@python.org
> To unsubscribe send an email to python-dev-le...@python.org
> https://mail.python.org/mailman3/lists/python-dev.python.org/
> Message archived at 
> https://mail.python.org/archives/list/python-dev@python.org/message/L5Q27DVKOKZCDNCAWRIQVOZ5DZCZHLRM/
> Code of Conduct: http://python.org/psf/codeofconduct/

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

[Python-Dev] Re: Move support of legacy platforms/architectures outside Python

[Barry Scott]

> On 22 Feb 2021, at 12:40, Michał Górny  wrote:
> 
>> I'm talking about 16-bit memory alignment which causes SIGBUS if it's
>> not respected on m68k.
>> 
> 
> I don't understand why you consider this to be a problem.  After all,
> x86 has stronger (32-bit) alignment requirements, so m68k is actually
> less likely to break.

On x86 you can make unaligned access to memory.
Alignment is a nice to have for performance.

But on m68k you MUST align or you get a SIGBUS.

Barry

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

[Python-Dev] Re: [Python-ideas] Inadequate error reporting during function call setup stage

[Barry Scott]

> On 22 Feb 2021, at 10:15, Paul Sokolovsky  wrote:
> 
> It looks like:
> 
> Traceback (most recent call last):
>  File "pseudoc_tool.py", line 91, in 
>  File ".../xforms.py", line 25, in print
> TypeError: unexpected keyword argument 'noann'
> 
> - that makes clear that it's "print" function of "xforms.py" module,
> line 25, which got an unexpected keyword argument.

You are proposing to fake a stack frame that I have to know is not a stack 
frame but is in fact the location of the function in the exception?
I'm -1 on that as its confusing.

Having checked that its python code and not a C extension function you could 
use the info
in fn.__code__ to get the filename and line of where the function is defined 
and put that info into the exception.

Example of the info:
| >>> os.path.join.__code__


I use repr(fn.__code__) a lot when debugging complex code.

Barry

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

[Python-Dev] Re: [RELEASE] Python 3.9.2rc1 and 3.8.8rc1 are now available for testing

[Barry Scott]

I think this fix for the limited API on Windows is not in the RC.
I could not fine the new code in the tarball.

Can it be added?

https://bugs.python.org/issue43155 

Barry


> On 17 Feb 2021, at 12:50, Łukasz Langa  wrote:
> 
> I’m happy to announce two release candidates today: Python 3.9.2rc1, and 
> Python 3.8.8rc1. Get them from:
> 
> https://www.python.org/downloads/release/python-392rc1/ 
> 
> 
> https://www.python.org/downloads/release/python-388rc1/ 
> 
> 
> Unless critical issues are discovered, both release candidates will become 
> their respective final versions on Monday, March 1st.
> Following that, the last full regular maintenance release of Python 3.8 is 
> planned for May 3rd 2021, after which it will shift to source releases only 
> for security bug fixes only. Maintenance releases for the 3.9 series will 
> continue at regular bi-monthly intervals, with 3.9.3 planned for early May 
> 2021.
> 
> Notable security content in today’s releases
> 
> bpo-42967 : Fix web cache poisoning 
> vulnerability by defaulting the query args separator to &, and allowing the 
> user to choose a custom separator.
> 
> bpo-42938 : Avoid static buffers when 
> computing the repr of ctypes.c_double and ctypes.c_longdouble values.
> 
> What’s new?
> 
> The Python 3.9 series contains many new features and optimizations over 3.8. 
> See the “What’s New in Python 3.9 
> ” document for more 
> information about features included in the 3.9 series. We also have a 
> detailed change log for 3.9.2rc1 
>  
> specifically.
> 
> Detailed information about all changes made in version 3.8.8rc1 specifically 
> can be found in its change log 
> .
> 
> We hope you enjoy those new releases!
> 
> Thanks to all of the many volunteers who help make Python Development and 
> these releases possible! Please consider supporting our efforts by 
> volunteering yourself or through organization contributions to the Python 
> Software Foundation.
> 
> Your friendly release team,
> Ned Deily @nad 
> Steve Dower @steve.dower 
> Łukasz Langa @ambv 
> ___
> Python-Dev mailing list -- python-dev@python.org
> To unsubscribe send an email to python-dev-le...@python.org
> https://mail.python.org/mailman3/lists/python-dev.python.org/
> Message archived at 
> https://mail.python.org/archives/list/python-dev@python.org/message/T4IZOGQB7DW4KNKJZBQ6U4VMYETK6EVR/
> Code of Conduct: http://python.org/psf/codeofconduct/

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

[Python-Dev] python limited API missing PyCMethod_New on Windows for 3.9 and 3.10

[Barry Scott]

I raised https://bugs.python.org/issue43155 for the missing
PyCMethod_New that was added in 3.9 but is missing from the
python3.lib.

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

[Python-Dev] Change windows installation program name

[Barry Scott]

I raise https://bugs.python.org/issue43156 that suggests that
new users on windows would be less confused if the name of the 
installation program did not seem to imply it was the python program.

In a nutshell the proposal is to change from this:

  python-3.10.0a5.exe
  python-3.10.0a5-amd64.exe

to this (thanks to Matthew Barnett for the improved names:

  python-3.10.0a5-win32-setup.exe
  python-3.10.0a5-win64-setup.exe

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

[Python-Dev] Re: Should python installation modify /etc/paths.d on Mac OS X?

[Barry Scott]

> On 14 Jan 2021, at 14:22, Peng Yu  wrote:
> 
> Hi,
> 
> The /etc/paths.d directory on Mac OS X contains the following
> directory. Some packages have their PATH variables set there.
> 
> For Python, I have to set the PATH manually in my ~/.bashrc. Should
> the Python developers consider setting PATH in /etc/paths.d as well?
> 
> ==> /etc/paths.d/100-rvictl <==
> /Library/Apple/usr/bin
> 
> ==> /etc/paths.d/40-XQuartz <==
> /opt/X11/bin
> 
> ==> /etc/paths.d/com.vmware.fusion.public <==
> /Applications/VMware Fusion.app/Contents/Public

One of the things that I wish the python macOS installed would stop doing is
editing my .bashrc/.zshrc etc.

After each python install I have to undo the edits to .bashrc or .zshrc that 
break
my environment.

I understand the motivation to do this. But please provide a why to turn this 
off
for for people like me that have many versions of python installed.

I think of two things that could be checked for.
1. A marked in the .bashrc/.zshrc file. '# python-disable-path-edit'
2. A file in ~/Library somewhere that disabled the behavour

Barry



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

[Python-Dev] Re: PEP 642 v3: Explicit patterns for structured pattern matching

[Barry Scott]

> On 3 Jan 2021, at 15:21, Nick Coghlan  wrote:
> 
> I’ve made a final round of updates to PEP 642 and submitted it to the
> Steering Council for consideration alongside PEP 634.
> 
> As usual, the rendered version can be found here:
> https://www.python.org/dev/peps/pep-0642/
> 
> There's a Discourse thread at
> https://discuss.python.org/t/pep-642-v3-explicit-pattern-syntax-for-structural-pattern-matching/6459,
> and the rest of the email covers the same points as the opening post
> in that thread.
> 
> There are some pretty significant changes relative to v2, although I
> did already discuss most of them in the v2 thread at
> https://discuss.python.org/t/pep-642-constraint-pattern-syntax-for-structural-pattern-matching/5614
> 
> The PEP itself contains a list of major changes relative to PEP 634,
> so I won’t repeat that here:
> https://www.python.org/dev/peps/pep-0642/#appendix-c-summary-of-changes-relative-to-pep-634
> 
> Instead I’ll summarise the parts that I consider most important:
> 
> * ensuring that all “binding to the right” operations use the as
> keyword. This drove changes to both mapping patterns and class
> patterns.
> * explicitly qualifying both name bindings and value constraints with
> `as`, `==`, or `is`. This change makes it possible to make pattern
> matching available to users without having to resolve the thorny
> questions of what bare names and attribute references should do by
> default. It also opens up the possibility of potentially adding more
> value constraint options later (like `in` , `is not`, and `!=`) if
> those operations seem sufficiently compelling to be worth adding.
> * explicitly decoupling sequence pattern matching from iterable
> unpacking. The change to require qualification of name binding
> operations already breaks the alignment between the two, and that
> created an opportunity to simplify the grammar by only allowing square
> bracket based sequence patterns and eliminating both open sequence
> patterns and parenthesis based sequence patterns
> * changing class patterns to draw more of their syntactic inspiration
> from mapping patterns rather than from class instantiation
> * explicitly representing patterns in the AST, rather than treating
> patterns as pseudo-expressions all the way through to the code
> generation layer. Skipping this step makes the code fragile and hard
> to follow, as there isn’t actually any point in the AST that accepts
> both expressions and patterns, but with pattern parsing reusing
> expression nodes, you can’t tell from just looking at the AST which
> nodes expect subexpressions and which expect subpatterns.
> 
> I’ll also quote the example match statement from the PEP abstract,
> which extracts “host” and “port” details from a 2 item sequence, a
> mapping with “host” and “port” keys, any object with “host” and “port”
> attributes, or a “host:port” string, treating the “port” as optional
> in the latter three cases:
> 
>port = DEFAULT_PORT
>match expr:
>case [as host, as port]:
>pass
>case {"host" as host, "port" as port}:
>pass
>case {"host" as host}:
>pass
>case object{.host as host, .port as port}:
>pass
>case object{.host as host}:
>pass
>case str{} as addr:
>host, __, optional_port = addr.partition(":")
>if optional_port:
>port = optional_port
>case __ as m:
>raise TypeError(f"Unknown address format: {m!r:.200}")
>port = int(port)

I read the above and believe I know what it meant without needing to read the 
PEP in detail.
I like that a lot.

I quickly read 642 v3 and missed an explanation about why the syntax to match a 
string object is
str{} and not str. Are you saying that I MUST use {} so that when case is 
parsed its clear that its a class
with no constraints?

in the "Changes to class patterns" I read the BinaryOp example and
I thought from the above that it would also use {} and not ().
---
match expr:
case BinaryOp(== '+', as left, as right):
---
I was expecting to see:
---
match expr:
case BinaryOp{== '+', as left, as right}:
---


Barry


> 
> Cheers,
> Nick.
> 
> -- 
> Nick Coghlan   |   ncogh...@gmail.com   |   Brisbane, Australia
> ___
> Python-Dev mailing list -- python-dev@python.org
> To unsubscribe send an email to python-dev-le...@python.org
> https://mail.python.org/mailman3/lists/python-dev.python.org/
> Message archived at 
> https://mail.python.org/archives/list/python-dev@python.org/message/GQHKW5KHXWZ3Y2E2KOJ72GT3IRGGEEUE/
> Code of Conduct: http://python.org/psf/codeofconduct/

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

[Python-Dev] Re: How to customize CPython to a minimal set

[Barry Scott]

There are tools in the python ecosystem that know how to build stand alone apps 
for
python. These tools can figure out the minimum set of python and 
.so/.dylib/.dll that are needed.

I use these tools when building apps for Windows and macOS where I do not 
require
that python is pre-installed. You can use the same technics for unix systems.

1. Start with standard python
2. pip install deps
3. run tool to create minimum app

If you build multiple apps then you can share common files to cut down size as 
well.

Barry


> On 22 Jul 2020, at 14:31, Huang, Yang  wrote:
> 
> Thank you for all your comments. 
> I cannot agree any more. I did try but there were so many dependencies. One 
> change all change.
>  
> Micropython is a choice. But not sure if numpy and sqlite3 can be supported 
> well. And what’s the compatibility of the libs in Pypi.  
>  
>  
> From: Guido van Rossum mailto:gu...@python.org>> 
> Sent: Tuesday, July 21, 2020 10:57 PM
> To: Huang, Yang mailto:yang.hu...@intel.com>>
> Cc: python-dev@python.org 
> Subject: Re: [Python-Dev] How to customize CPython to a minimal set
>  
> I expect it will be unfeasible to strip CPython. If you disagree, try it. ;-)
>  
> On Mon, Jul 20, 2020 at 22:35 Huang, Yang  > wrote:
> Hi, Guido
>  
> Yes. Micropyhton is also in consideration.
> But sqlite3 is the first usage. There should be some additional features like 
> numpy, scipy... Not sure if micropython supports well?
>  
> Or is there a feasible way to strip CPython ?
>  
> Thanks.
>  
> From: Guido van Rossum mailto:gu...@python.org>> 
> Sent: Monday, July 20, 2020 10:45 PM
> To: Huang, Yang mailto:yang.hu...@intel.com>>
> Cc: python-dev@python.org 
> Subject: Re: [Python-Dev] How to customize CPython to a minimal set
>  
> Have you considered starting with micropython? It’s made for embedded systems 
> and fully supports Python 3 syntax. Adding sqlite3 support to it will be less 
> work than stripping all the I/O from CPython.
>  
> —Guido
>  
> On Mon, Jul 20, 2020 at 06:48 Huang, Yang  > wrote:
> 
> Hi, all
> 
> There is a request to run python in a Linux-based embedded resource 
> constrained system with sqlite3 support.
> 
> So many features are not required, like posixmodule, signalmodule, hashtable 
> ...
> But seems there are some dependencies among the 
> Modules/Parser/Python/Objects/Programs...
> 
> Is there a way to tailor CPython 3 to a minimal set with sqlite3 (the less 
> syscalls the better) ? 
> Is it possible to do that?
> 
> Thank you.
> ___
> Python-Dev mailing list -- python-dev@python.org 
> 
> To unsubscribe send an email to python-dev-le...@python.org 
> 
> https://mail.python.org/mailman3/lists/python-dev.python.org/ 
> 
> Message archived at 
> https://mail.python.org/archives/list/python-dev@python.org/message/ECPLKXQ42VNLHD5DP3RG57L3QTJ77FUT/
>  
> 
> Code of Conduct: http://python.org/psf/codeofconduct/ 
> 
> --
> --Guido (mobile)
> -- 
> --Guido (mobile)
> ___
> Python-Dev mailing list -- python-dev@python.org 
> 
> To unsubscribe send an email to python-dev-le...@python.org 
> 
> https://mail.python.org/mailman3/lists/python-dev.python.org/ 
> 
> Message archived at 
> https://mail.python.org/archives/list/python-dev@python.org/message/OMUGASSNBFJOT3W2ES4OIOQ4LOWMNHHG/
>  
> 
> Code of Conduct: http://python.org/psf/codeofconduct/ 
> 
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/IFOGVDZFASRHKSJO46Q74UFCKXPULVOL/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Plan to remove Py_UNICODE APis except PEP 623.

[Barry Scott]

> On 30 Jun 2020, at 13:43, Emily Bowman  wrote:
> 
> I completely agree with this, that UTF-8 has become the One True 
> Encoding(tm), and UCS-2 and UTF-16 are hardly found anywhere outside of the 
> Win32 API. Nearly all basic emoji can't be represented in UCS-2 wchar_t, let 
> alone composite emoji.
> 

I use UCS-32 in my extensions, but never persist UCS-32 for which I use UTF-8.

If you are calling WIN32 "unicode" APIs then you need UCS-16.

My plan with PyCXX is to replace Py_UNICODE with UCS-32.
I think all the UCS-32 APIs will still be present.

Once I add that support to PyCXX all my users should easily port to a 
non-Py_UNICODE world.

Barry

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

[Python-Dev] Re: Plan to remove Py_UNICODE APis except PEP 623.

[Barry Scott]

> On 29 Jun 2020, at 10:57, Victor Stinner  wrote:
> 
> I would prefer to only have a fast-path for the most common encodings:
> ASCII, Latin1, UTF-8, Windows ANSI code page. That's all.

It's not obvious to me why the latin1 encoding is in this list as its just one 
of all the 8-bit char sets.
Why is it needed?

Barry

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

[Python-Dev] Re: Can we stop adding to the C API, please?

[Barry Scott]

> On 4 Jun 2020, at 16:34, Victor Stinner  wrote:
> 
> Le jeu. 4 juin 2020 à 00:14, Nathaniel Smith  a écrit :
>> On Wed, Jun 3, 2020 at 2:10 PM Victor Stinner  wrote:
>>> For the short term, my plan is to make structure opaque in the limited
>>> C API, before breaking more stuff in the public C API :-)
>> 
>> But you're also breaking the public C API:
>> https://github.com/MagicStack/immutables/issues/46
>> https://github.com/pycurl/pycurl/pull/636
>> 
>> I'm not saying you're wrong to do so, I'm just confused about whether
>> your plan is to break stuff or not and on which timescale.
> 
> Yes, my plan includes backward incompatible changes on purpose:
> https://github.com/vstinner/misc/blob/master/cpython/pep-opaque-c-api.rst#api-and-abi-incompatible-changes
> 
> The practical issue is to estimate how many C extension modules are
> broken by a specific C API change. I plan to help out to port C
> extensions to the updated C API. If the number of broken extensions is
> fine and updating them is easy/short: fine! If the number is too high,
> we have until "3.10.0 final: Monday, 2021-10-04" to revert
> incompatible changes which caused most troubles.
> 

snip

My experience with keeping PyCXX up to date with these changes is that its not 
hard
to be compatible. I support python 3.4 to 3.9 for limited and unlimited API.
(I also support python 2.7 with the same unlimited API)

Barry


> 
> Victor
> -- 
> Night gathers, and now my watch begins. It shall not end until my death.
> ___
> Python-Dev mailing list -- python-dev@python.org
> To unsubscribe send an email to python-dev-le...@python.org
> https://mail.python.org/mailman3/lists/python-dev.python.org/
> Message archived at 
> https://mail.python.org/archives/list/python-dev@python.org/message/23LYPNHSSIWIZKMTUYXPRHQQRH5TKPGC/
> Code of Conduct: http://python.org/psf/codeofconduct/
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/KLNOMA5UBPBGJNANA6YK7EWSI6LNAR7R/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: PoC: Subinterpreters 4x faster than sequential execution or threads on CPU-bound workaround

[Barry Scott]

> On 5 May 2020, at 23:40, Guido van Rossum  wrote:
> 
> Is there some kind of optimized communication possible yet between 
> subinterpreters? (Otherwise I still worry that it's no better than 
> subprocesses -- and it could be worse because when one subinterpreter 
> experiences a hard crash or runs out of memory, all others have to die with 
> it.)
> 

I had already concluded that this would not be useful for the use cases I have 
at work.
The running out of memory and the hard crash is what would stop me using this 
in production.

For my day job I work on a service that forks slave processes to handle I/O 
transactions.
There is a monitor process that manages the total memory of all slaves and 
shutdown and replaces
slaves when they use too much memory. Typically there are 60 to 100 slaves with 
a core each to play with.
The service runs 24x365.

Barry

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

[Python-Dev] Re: Providing fix for modulefinder.py regression on Windows

[Barry Scott]

> On 12 Apr 2020, at 21:49, Eric V. Smith  wrote:
> 
> On 4/12/2020 4:08 PM, Barry Scott wrote:
>> 
>>> On 11 Apr 2020, at 16:28, Barry Scott >> <mailto:ba...@barrys-emacs.org>> wrote:
>>> 
>>> modulefinder.py does not open source files in "rb" which
>>> prevents compile() from applying the encoding rules.
>>> 
>> snip
>> 
>> I have created the bpo, the pr and have the checks passing except that I 
>> need a NEWS.d entry
>> to make bedevere/news happy. I see the files have a special filename is that 
>> from an automatic
>> process of a tool I need to run?
>> 
>> Barry
>> 
> The tool is blurb (or the online blurb-it): 
> https://devguide.python.org/committing/#what-s-new-and-news-entries 
> <https://devguide.python.org/committing/#what-s-new-and-news-entries>
> 
I was reading this https://devguide.python.org/#contributing 
<https://devguide.python.org/#contributing> that does not mention blurb.

I would not have though to look in the section on Accepting Pull Requests, as 
that not what I'm doing.

Barry

> Eric
> 

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

[Python-Dev] Re: Providing fix for modulefinder.py regression on Windows

[Barry Scott]

> On 11 Apr 2020, at 16:28, Barry Scott  wrote:
> 
> modulefinder.py does not open source files in "rb" which
> prevents compile() from applying the encoding rules.
> 
snip

I have created the bpo, the pr and have the checks passing except that I need a 
NEWS.d entry
to make bedevere/news happy. I see the files have a special filename is that 
from an automatic
process of a tool I need to run?

Barry


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

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

[Python-Dev] Providing fix for modulefinder.py regression on Windows

[Barry Scott]

modulefinder.py does not open source files in "rb" which
prevents compile() from applying the encoding rules.

This first showed up for me on Windows with Python 3.8.

I'd like to provide patches for 3.8 (if any more releases)
and 3.9.

What is the process I should follow?
I have signed the Contributor Agreement.

Here is my test case and the results on Windows with 3.7.

import modulefinder

with open('import_functools.py', 'w') as f:
f.write('import functools\n')

mf = modulefinder.ModuleFinder()
mf.run_script('import_functools.py')
print('Test passed')

py -3.8-32 modulefinder_test.py
Traceback (most recent call last):
  File "modulefinder_test.py", line 7, in 
mf.run_script('import_functools.py')
  File "C:\Python38.win32\lib\modulefinder.py", line 165, in run_script
self.load_module('__main__', fp, pathname, stuff)
  File "C:\Python38.win32\lib\modulefinder.py", line 360, in load_module
self.scan_code(co, m)
  File "C:\Python38.win32\lib\modulefinder.py", line 433, in scan_code
self._safe_import_hook(name, m, fromlist, level=0)
  File "C:\Python38.win32\lib\modulefinder.py", line 378, in _safe_import_hook
self.import_hook(name, caller, level=level)
  File "C:\Python38.win32\lib\modulefinder.py", line 177, in import_hook
q, tail = self.find_head_package(parent, name)
  File "C:\Python38.win32\lib\modulefinder.py", line 233, in find_head_package
q = self.import_module(head, qname, parent)
  File "C:\Python38.win32\lib\modulefinder.py", line 326, in import_module
m = self.load_module(fqname, fp, pathname, stuff)
  File "C:\Python38.win32\lib\modulefinder.py", line 343, in load_module
co = compile(fp.read()+'\n', pathname, 'exec')
  File "C:\Python38.win32\lib\encodings\cp1252.py", line 23, in decode
return codecs.charmap_decode(input,self.errors,decoding_table)[0]
UnicodeDecodeError: 'charmap' codec can't decode byte 0x81 in position 308: 
character maps to 

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

[Python-Dev] Re: Proliferation of tstate arguments.

[Barry Scott]

> On 17 Mar 2020, at 16:43, Mark Shannon  wrote:
> 
> 
> 
> On 17/03/2020 3:38 pm, Steve Dower wrote:
>> On 17Mar2020 1447, Mark Shannon wrote:
>>> On 16/03/2020 3:04 pm, Victor Stinner wrote:
 In short, the answer is yes.
>>> 
>>> I said "no" then and gave reasons. AFAICT no one has faulted my reasoning.
>> I said "yes" then and was also not faulted.
> 
> I'll do that now then ;)
> 
> The accessibility of a thread-local variable is a strict superset of that of 
> a function-local variable.
> 
> Therefore storing the thread state in a thread-local variable is at least as 
> capable as passing thread-state as a parameter.
> 
>>> Let me reiterate why using a thread-local variable is better than passing 
>>> the thread state down the C stack.
>>> 
>>> 1. Using a thread-local variable for the thread state requires much smaller 
>>> changes to the code base.
>> Using thread-local variables enforces a threading model on the host 
>> application, rather than working with the existing threading model. So 
>> anyone embedding is forced into *significantly* more code as a result.
> 
> Putting a value in a function-local variable enforces stronger restrictions 
> than putting it in a thread-local variable.
> 
> I am proposing that we *don't* change the API. How does that make more work 
> for anyone using the API?

Are you saying that all interpreters can use the same thread-local-variable for 
tstate?

Or do you need N thread-local-variables for N interpreters?

Barry


> 
>> We can (and should) maintain a public-facing API that uses TLS to pass the 
>> current thread state around - we have compatibility constraints. But we can 
>> also add private versions that take the thread state (once you've started 
>> trying/struggling to really embed CPython, you'll happily take a dependency 
>> on "private" APIs).
> 
> Again, I am requesting that we *don't* change the API.
> Not changing the API maintains backwards compatibility better than changing 
> it, surely.
> 
>> If the only available API requires TLS, then you're likely to see the caller 
>> wrap it all up in a function that updates TLS before calling. Or 
>> alternatively, introduce dedicated threads for running Python snippets on, 
>> and all the (dead)locking that results (yes, I've done both).
> 
> All the platforms that we support have thread-local storage.
> If a platform doesn't have threads at all, then thread-local just degenerates 
> to a global.
> 
>> Our goal as core CPython developers should be to sacrifice our own effort to 
>> reduce the effort needed by our users, not to do things that make our own 
>> lives easier but harm them.
> 
> Indeed. We might want to speed Python up a bit as well :)
> 
>>> 2. Using a thread-local variable is less error prone. When passing tstate 
>>> as a parameter, what happens if the tstate argument is from a different 
>>> thread or is NULL? Are you adding checks for those cases?
>>> What are the performance implications of adding those checks?
>> Undefined behaviour is totally acceptable here. We can assert in debug 
>> builds - developers who make use of this can test with debug builds.
> 
> I'm not sure what your point is about undefined behaviour.
> 
>>> 3. Using a thread-local variable is likely to be a little bit faster. 
>>> Passing an argument down the stack increases register pressure and spills.
>>> Accessing a thread-local is slower at the point of access, but the cost is 
>>> incurred only when it is needed, so is cheaper overall.
>> Compilers can optimise parameters/locals in ways that are far more efficient 
>> than they can do for anything stored outside the call stack. Especially for 
>> internal calls. Going through public/exported functions is a little more 
>> restricted in terms of optimisations, but if we identify an issue here then 
>> we can work on that then.
> 
> Please skip the patronizing "how compilers work" stuff.
> I know how register allocators work.
> 
>> [OTHER POST]
>>> Just to be clear, this is what I mean by a thread local variable:
>>> https://godbolt.org/z/dpSo-Q
>> Showing what one particular compiler generates for one particular situation 
>> is terrible information (I won't bother calling it "evidence").
> 
> The particular situation is the use of a thread-local variable, which is the 
> point under discussion.
> 
> Here's the links for clang and MSVC:
> 
> https://godbolt.org/z/YnbbqD
> https://www.godbolt.ms/z/9nQEqf
> 
 One motivation is to ease the implementation of subinterpreters (PEP
 554). But PEP 554 describes more than public API than the
 implementation.
>>> 
>>> I don't see how this eases the implementation of subinterpreters.
>>> Surely it makes it harder by causing merge conflicts.
>> That's a very selfish point-of-view :)
> 
> Why? Merge conflicts are a problem for everyone.
> 
>> It eases it because many more operations need to know the current Python 
>> "thread" in order to access things that used to be globals, such as 
>> PyTypeObject 

[Python-Dev] Re: Request to postpone some Python 3.9 incompatible changes to Python 3.10

[Barry Scott]

> On 24 Jan 2020, at 08:40, Victor Stinner  wrote:
> 
> The change is that Python 2.7 is no longer supported (since 2020-01-01).
> 

Isn't there going to be a final Python 2.7 release in April 2020?

I know that Twisted has moved its python 2 removal to match the
April 2020 date. Other projects may have made the similar decisions.

Barry




> Victor
> 
> Le ven. 24 janv. 2020 à 09:19, Chris Angelico  a écrit :
>> 
>> On Fri, Jan 24, 2020 at 7:05 PM Victor Stinner  wrote:
>>> We kept a compatibility layer with Python 2 on purpose, PEP 4 says:
>>> 
>>> "In order to facilitate writing code that works in both Python 2 & 3
>>> simultaneously, any module that exists in both Python 3.5 and Python
>>> 2.7 will not be removed from the standard library until Python 2.7 is
>>> no longer supported as specified by PEP 373."
>>> 
>>> The rule was used since Python 3.0 until Python 3.8, but it changed in
>>> Python 3.9 which includes many incompatible changes for the first time
>>> in the Python 3 major version.
>> 
>> I'm sorry, I don't understand what 'changed'. Isn't that rule exactly
>> WHY 3.9 is the removal point? Python 2.7 is no longer supported, and
>> its final post-support release is scheduled earlier than 3.9's first
>> beta and feature freeze. Doesn't that mean that PEP 4 is being
>> followed precisely? What have I misunderstood?
>> 
>> ChrisA
>> ___
>> Python-Dev mailing list -- python-dev@python.org
>> To unsubscribe send an email to python-dev-le...@python.org
>> https://mail.python.org/mailman3/lists/python-dev.python.org/
>> Message archived at 
>> https://mail.python.org/archives/list/python-dev@python.org/message/GCCLU2O2QJTGECQKUYEHD2KVD3IKJTLE/
>> Code of Conduct: http://python.org/psf/codeofconduct/
> 
> 
> 
> -- 
> Night gathers, and now my watch begins. It shall not end until my death.
> ___
> Python-Dev mailing list -- python-dev@python.org
> To unsubscribe send an email to python-dev-le...@python.org
> https://mail.python.org/mailman3/lists/python-dev.python.org/
> Message archived at 
> https://mail.python.org/archives/list/python-dev@python.org/message/6YLZXTOJJ7XGISGRITJV7OAEOEKFYZS7/
> Code of Conduct: http://python.org/psf/codeofconduct/
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/C65AAFHWSN46SI5NBF735MPF242NRSQC/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Why doesn't venv also install python3*-config?

[Barry Scott]

> On 12 Jan 2020, at 16:20, mus...@posteo.org wrote:
> 
> Hi guys,
> 
> after I got the whole list into a lather about the merits of
> the python-config program, let me rephrase the question:
> 
> Is there a "canonical" way of automatically finding the correct
> include files and Python runtime library when embedding the Python
> interpreter, based on the current virtual environment (and not the
> "installed" version)? Upon reding the docs there isn't. And maybe there
> should't or cant be any. So if I want to try embedding Python under
> different versions I have to either install those into different
> directories and use python-config, or I write a trivial Python program
> that finds the correct values for the current environment using
> sysconfig and outpus those as compiler / linker flags. Easy enough, I
> was just surprised that no such solution was already built into the
> virtualenv setup mechanism
> 
> Here's a quote from the docs
> """
> If this procedure [using python-config] doesn’t work for you (it is not
> guaranteed to work for all Unix-like platforms; however, we welcome bug
> reports) you will have to read your system’s documentation about
> dynamic linking and/or examine Python’s Makefile (use
> sysconfig.get_makefile_filename() to find its location) and compilation
> options. In this case, the sysconfig module is a useful tool to
> programmatically extract the configuration values that you will want to
> combine together. For example:
> 
 import sysconfig
 sysconfig.get_config_var('LIBS')
> '-lpthread -ldl  -lutil'
 sysconfig.get_config_var('LINKFORSHARED')
> '-Xlinker -export-dynamic'
> """

I build a python C++ extension called pysvn. It's build system works
by running a python program to generate a native makefile for
Windows, macOS, Fedora, NetBSD etc. The code support
python 2 and all the python 3's.

I have all the python versions installed on my build systems
side-by-side. I did not need to use venv as all the python's
are installled into the systems.

Maybe you can use some of the ideas from the code.
See this module:

https://svn.code.sf.net/p/pysvn/code/trunk/pysvn/Extension/Source/setup_configure.py
 


Barry


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

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

Re: [Python-Dev] windows compiler list missing 3.7 details on wiki

[Barry Scott]

> On 3 Nov 2018, at 17:57, Steve Dower  wrote:
> 
> Yes. Visual Studio 2015 or later can be used (and as this is the only way to 
> get the compiler right now, I think it's fine to list that as the requirement 
> - note that the "Visual Studio Build Tools" installer doesn't include the IDE 
> itself).
> 
> Feel free to update the wiki.

Just got around to doing this. That page is marked as Immutable Page for me.

Do I need to apply for edit permissions? I'm user BarryScott on the wiki.

Barry


> 
> Cheers,
> Steve
> 
> On 03Nov2018 0208, Barry Scott wrote:
>> On https://wiki.python.org/moin/WindowsCompilers details for 3.7 are missing.
>> I'm assuming its still VC V14
>> 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/archive%40mail-archive.com

Re: [Python-Dev] subprocess not escaping "^" on Windows

[Barry Scott]

My feeling is that the number of uses for calling cmd /c is rather limited on 
Windows.

Certainly calling out to use the CMD builtin is not to be encouraged I'd say.
Between shutil and the os module you have most of the file handling commands.
Admin tools might want to run special commands, but they are not builtins.

In all the cases where you have a command line exe to run you can avoid
calling into cmd and the associated quoting problems.

I've found that in all my windows python apps I typically end up using 
CreateProcess
and ShellExecute for the useful stuff. (I use ctypes to call them).

Is it worth changing the quoting at all? I would say not.

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

Re: [Python-Dev] iso8601 parsing

[Barry Scott]

> On 26 Oct 2017, at 17:45, Chris Barker  wrote:
> 
> This is a key point that I hope is obvious:
> 
> If an ISO string has NO offset or timezone indicator, then a naive datetime 
> should be created.
> 
> (I say, I "hope" it's obvious, because the numpy datetime64 implementation 
> initially (and for years) would apply the machine local timezone to a bare 
> iso string -- which was a f-ing nightmare!)


I hope the other obvious thing is that if there is a offset then a datetime 
that is *not* naive can be created
as it describes an unambiguous point in time. We just cannot know what 
political timezone to choose.
I'd guess that it should use the UTC timezone in that case.

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

[Python-Dev] Python3 C extension how to support dir()

[Barry Scott]

I first ask this on python users. But I think the only people that can answer 
are the core developers.

I have a python3 C++ extension that works written using the PyCXX C++ interface.

But dir(obj) does not return the list of member variables.

With the python2 version supporting the __members__ variable was all that was 
needed.
But __members__ been removed from python3.

How should I support dir() from the C API?

I cannot use tp_members, not appropiate to the code I'm writing.
If I provide __dir__ I then hit the problem I need the C API version of:

all_attr = super( mytype, obj ).__dir__();
all_attr.extend( mytype_variable_names );
return all_attr

I'm not getting inspiration from the python 3.6 sources for this problem.

I did find the object_dir function in typeobject.c, but that has not helped
get me move forward.

What is the the patten that I should implement?

Barry
PyCXX

___
Python-Dev mailing list
Python-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] Preference for of patch submission?

[Barry Scott]

I am over due providing a patch for a doc issue that was discussed on
the ideas list.

What is the preferred way to provide cpython with a patch these days?

bug report + patch?
pull request on github?
something else?

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

Re: [Python-Dev] PEP 514: Python registration in the Windows registry

[Barry Scott]

Why do you need SysArchitecture? Surely the 32bit pythons are registered in the 
32bit registry and the 64 bit pythons in the 64 bit registry.

you can side by side install python 3.4 but only if you install 64 bit first 
then 32 bit second.

Barry


> On 15 Jul 2016, at 23:20, Steve Dower  wrote:
> 
> Hi all
> 
> I'd like to get this PEP approved (status changed to Active, IIUC).
> 
> So far (to my knowledge), Anaconda is writing out the new metadata and Visual 
> Studio is reading it. Any changes to the schema now will require somewhat 
> public review anyway, so I don't see any harm in approving the PEP right now.
> 
> To reiterate, this doesn't require changing anything about CPython at all and 
> has no backwards compatibility impact on official releases (but hopefully it 
> will stop alternative distros from overwriting our essential metadata and 
> causing problems).
> 
> I suppose I look to Guido first, unless he wants to delegate to one of the 
> other Windows contributors?
> 
> Cheers,
> Steve
> 
> URL: https://www.python.org/dev/peps/pep-0514/
> 
> Full text
> ---
> 
> PEP: 514
> Title: Python registration in the Windows registry
> Version: $Revision$
> Last-Modified: $Date$
> Author: Steve Dower 
> Status: Draft
> Type: Informational
> Content-Type: text/x-rst
> Created: 02-Feb-2016
> Post-History: 02-Feb-2016, 01-Mar-2016
> 
> Abstract
> 
> 
> This PEP defines a schema for the Python registry key to allow third-party
> installers to register their installation, and to allow applications to detect
> and correctly display all Python environments on a user's machine. No
> implementation changes to Python are proposed with this PEP.
> 
> Python environments are not required to be registered unless they want to be
> automatically discoverable by external tools.
> 
> The schema matches the registry values that have been used by the official
> installer since at least Python 2.5, and the resolution behaviour matches the
> behaviour of the official Python releases.
> 
> Motivation
> ==
> 
> When installed on Windows, the official Python installer creates a registry 
> key
> for discovery and detection by other applications. This allows tools such as
> installers or IDEs to automatically detect and display a user's Python
> installations.
> 
> Third-party installers, such as those used by distributions, typically create
> identical keys for the same purpose. Most tools that use the registry to 
> detect
> Python installations only inspect the keys used by the official installer. As 
> a
> result, third-party installations that wish to be discoverable will overwrite
> these values, resulting in users "losing" their Python installation.
> 
> By describing a layout for registry keys that allows third-party installations
> to register themselves uniquely, as well as providing tool developers guidance
> for discovering all available Python installations, these collisions should be
> prevented.
> 
> Definitions
> ===
> 
> A "registry key" is the equivalent of a file-system path into the registry. 
> Each
> key may contain "subkeys" (keys nested within keys) and "values" (named and
> typed attributes attached to a key).
> 
> ``HKEY_CURRENT_USER`` is the root of settings for the currently logged-in 
> user,
> and this user can generally read and write all settings under this root.
> 
> ``HKEY_LOCAL_MACHINE`` is the root of settings for all users. Generally, any
> user can read these settings but only administrators can modify them. It is
> typical for values under ``HKEY_CURRENT_USER`` to take precedence over those 
> in
> ``HKEY_LOCAL_MACHINE``.
> 
> On 64-bit Windows, ``HKEY_LOCAL_MACHINE\Software\Wow6432Node`` is a special 
> key
> that 32-bit processes transparently read and write to rather than accessing 
> the
> ``Software`` key directly.
> 
> Structure
> =
> 
> We consider there to be a single collection of Python environments on a 
> machine,
> where the collection may be different for each user of the machine. There are
> three potential registry locations where the collection may be stored based on
> the installation options of each environment::
> 
>HKEY_CURRENT_USER\Software\Python\\
>HKEY_LOCAL_MACHINE\Software\Python\\
>HKEY_LOCAL_MACHINE\Software\Wow6432Node\Python\\
> 
> Environments are uniquely identified by their Company-Tag pair, with two 
> options
> for conflict resolution: include everything, or give priority to user
> preferences.
> 
> Tools that include every installed environment, even where the Company-Tag 
> pairs
> match, should ensure users can easily identify whether the registration was
> per-user or per-machine.
> 
> When tools are selecting a single installed environment from all registered
> environments, the intent is that user preferences from ``HKEY_CURRENT_USER``
> will override matching Company-Tag pairs in ``HKEY_LOCAL_MACHINE``.
> 
> Official Python releases use 

Re: [Python-Dev] Maybe, just maybe, pathlib doesn't belong.

[Barry Scott]

On Mon, 11 Apr 2016 14:15:02 -0700
Ethan Furman  wrote:

> We've pretty decided that we have two options:
> 
> 1. remove pathlib
> 2. make the stdlib work with pathlib
> 
> So we're trying to make option 2 work before falling back to option 1.

I have been doing a lot of porting to Python 3 and have really enjoyed
having pathlib, even in its current state.

In one of my previous projects using python 2 on linux we had to code to
handle files with names that where not utf-8. (Users could FTP a file
into the file system and it could end up non-utf-8).

Today we would have used pathlib to represent paths in the app.
But we would need to be able to detect the paths that do not following 
the fs encoding rules.

I would suggest a predicate in Path to report that the path cannot be
encoding without the use of surrogates. Not sure what to call the
predicate.

This can be used by code that cares to handle converting the path into
a suitable presentation string for showing to a user. I'm assuming here
that PEP383 may not provide an presentation string that is suitable for
showing to users.

In the case of our product we refused to use files that did not encode
to utf-8 and had a UI to allow the user to fix the name. 

One reason for files that can only be represented as bytes()
being detectable I suspect is to avoid security issues. I think
if I have my black hat on I would probe a python3 app with filenames
that are non-utf-8 and see if I can break the app.

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

Re: [Python-Dev] python windows installation inconsistent use of registry keys

[Barry Scott]

> On 15 Sep 2015, at 18:39, Barry Scott <ba...@barrys-emacs.org> wrote:
> 
> I am used to looking in 
> HKLM:\SOFTWARE\Python\PythonCore\%(py_maj)d.%(py_min)d\InstallPath
> to find out where python is installed so that my installation kit can add 
> itself to site-packages.
> 
> I just found that the registry key used for 32 bit python 3.5 on windows 
> changed to be '3.5-32',
> which I can change my installer to cope with.
> 
> However the key for the 64bit install is ‘3.5’ but not '3.5-64'.
> 
> Why was this changed and why not consistently between 32 and 64 bit versions?
> 

Raised as bug http://bugs.python.org/issue25148

> Barry
> PyCXX, PySVN maintainer
> 
> ___
> Python-Dev mailing list
> Python-Dev@python.org
> https://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe: 
> https://mail.python.org/mailman/options/python-dev/barry%40barrys-emacs.org

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

[Python-Dev] python windows installation inconsistent use of registry keys

[Barry Scott]

I am used to looking in 
HKLM:\SOFTWARE\Python\PythonCore\%(py_maj)d.%(py_min)d\InstallPath
to find out where python is installed so that my installation kit can add 
itself to site-packages.

I just found that the registry key used for 32 bit python 3.5 on windows 
changed to be '3.5-32',
which I can change my installer to cope with.

However the key for the 64bit install is ‘3.5’ but not '3.5-64'.

Why was this changed and why not consistently between 32 and 64 bit versions?

Barry
PyCXX, PySVN maintainer

___
Python-Dev mailing list
Python-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] PYTHONPATH processing change from 2.6 to 2.7 and Mac bundle builder problems

[Barry Scott]

Issue filed as http://bugs.python.org/issue16821

I now have a fix that I can use, a trivia patch to the bundlebuilder.py from 2.6
gives me working code.

The bundelbuilder in 2.7 is not in good shape, the code changes from the 2.6
version have bugs in them, at least one is a show stopper. I'd have to assume
that the code was not tested.

I'd suggest that you revert to the 2.6 version and apply the patch in the bug
report so that this can make it into a 2.7.4 if you do another 2.7 release.

I also noticed that it says that bundelbuilder will not be in python 3.
Do you expect this functionality to be maintained outside of the core
python code?

Barry


On 28 Dec 2012, at 23:57, Ned Deily n...@acm.org wrote:

 In article 9e6e3321-b0e7-4e77-afcb-9c7855649...@barrys-emacs.org,
 Barry Scott ba...@barrys-emacs.org wrote:
 You did not set PYTHONHOME that effects the code in calculate_path a lot.
 Also there is platform specific code in tht code.
 On 28 Dec 2012, at 22:30, Antoine Pitrou solip...@pitrou.net wrote:
 On Fri, 28 Dec 2012 21:39:56 +
 Barry Scott ba...@barrys-emacs.org wrote:
 I'm trying to track down why bundlebuilder no longer works with python 2.7
 to create runnable Mac OS X apps.
 
 I have got as far as seeing that imports of modules are failing.
 
 What I see is that sys.path does not contain all the elements from the
 PYTHONPATH variable.
 
 No matter what I put in PYTHONPATH only the first element is in sys.path.
 
 I can't reproduce under Linux:
 
 $ PYTHONPATH=/x:/y python -Sc import sys; print(sys.path)
 ['', '/x', '/y', '/usr/lib/python27.zip', '/usr/lib64/python2.7/',
 '/usr/lib64/python2.7/plat-linux2', '/usr/lib64/python2.7/lib-tk',
 '/usr/lib64/python2.7/lib-old', '/usr/lib64/python2.7/lib-dynload']
 
 Barry,
 
 I think this discussion should be taking place on the bug tracker 
 (http://bugs.python.org), rather than in python-dev.  bundlebuilder is 
 unique to OS X and fairly esoteric.  Please open an issue there and 
 include a sample of how you created an app with bundlebuilder and what 
 Python 2.7 version you are using and what version of OS X.
 
 Thanks!
 
 -- 
 Ned Deily,
 n...@acm.org
 
 ___
 Python-Dev mailing list
 Python-Dev@python.org
 http://mail.python.org/mailman/listinfo/python-dev
 Unsubscribe: 
 http://mail.python.org/mailman/options/python-dev/barry%40barrys-emacs.org
 

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

[Python-Dev] PYTHONPATH processing change from 2.6 to 2.7 and Mac bundle builder problems

[Barry Scott]

I'm trying to track down why bundlebuilder no longer works with python 2.7
to create runnable Mac OS X apps.

I have got as far as seeing that imports of modules are failing.

What I see is that sys.path does not contain all the elements from the
PYTHONPATH variable.

No matter what I put in PYTHONPATH only the first element is in sys.path.

In detail here is what I'm using to test this:

$ export 
PYTHONHOME=/Users/barry/wc/svn/pysvn/WorkBench/Kit/MacOSX/tmp/pysvn_workbench_svn178-1.6.6-0-x86_64/WorkBench.app/Contents/Resources
$ export 
PYTHONPATH=/Users/barry/wc/svn/pysvn/WorkBench/Kit/MacOSX/tmp/pysvn_workbench_svn178-1.6.6-0-x86_64/WorkBench.app/Contents/Resources:/Users/barry/wc/svn/pysvn/WorkBench/Kit/MacOSX/tmp/pysvn_workbench_svn178-1.6.6-0-x86_64/WorkBench.app/Contents/Resources/Modules.zip

$ python2.7 -c import sys;print sys.path
['', 
'/Users/barry/wc/svn/pysvn/WorkBench/Kit/MacOSX/tmp/pysvn_workbench_svn178-1.6.6-0-x86_64/WorkBench.app/Contents/Resources']

$ python2.6 -c import sys;print sys.path
'import site' failed; use -v for traceback
['', 
'/Users/barry/wc/svn/pysvn/WorkBench/Kit/MacOSX/tmp/pysvn_workbench_svn178-1.6.6-0-x86_64/WorkBench.app/Contents/Resources',
 
'/Users/barry/wc/svn/pysvn/WorkBench/Kit/MacOSX/tmp/pysvn_workbench_svn178-1.6.6-0-x86_64/WorkBench.app/Contents/Resources/Modules.zip',
 
'/Users/barry/wc/svn/pysvn/WorkBench/Kit/MacOSX/tmp/pysvn_workbench_svn178-1.6.6-0-x86_64/WorkBench.app/Contents/Resources/lib/python26.zip',
 
'/Users/barry/wc/svn/pysvn/WorkBench/Kit/MacOSX/tmp/pysvn_workbench_svn178-1.6.6-0-x86_64/WorkBench.app/Contents/Resources/lib/python2.6/',
 
'/Users/barry/wc/svn/pysvn/WorkBench/Kit/MacOSX/tmp/pysvn_workbench_svn178-1.6.6-0-x86_64/WorkBench.app/Contents/Resources/lib/python2.6/plat-darwin',
 
'/Users/barry/wc/svn/pysvn/WorkBench/Kit/MacOSX/tmp/pysvn_workbench_svn178-1.6.6-0-x86_64/WorkBench.app/Contents/Resources/lib/python2.6/plat-mac',
 
'/Users/barry/wc/svn/pysvn/WorkBench/Kit/MacOSX/tmp/pysvn_workbench_svn178-1.6.6-0-x86_64/WorkBench.app/Contents/Resources/lib/python2.6/plat-mac/lib-
 scriptpackages', 
'/Users/barry/wc/svn/pysvn/WorkBench/Kit/MacOSX/tmp/pysvn_workbench_svn178-1.6.6-0-x86_64/WorkBench.app/Contents/Resources/lib/python2.6/lib-tk',
 
'/Users/barry/wc/svn/pysvn/WorkBench/Kit/MacOSX/tmp/pysvn_workbench_svn178-1.6.6-0-x86_64/WorkBench.app/Contents/Resources/lib/python2.6/lib-old',
 
'/Users/barry/wc/svn/pysvn/WorkBench/Kit/MacOSX/tmp/pysvn_workbench_svn178-1.6.6-0-x86_64/WorkBench.app/Contents/Resources/lib/python2.6/lib-dynload']

Any insight into what has changed and what might need changing in bundlebuilder 
would be appreciated.

Barry

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

Re: [Python-Dev] PYTHONPATH processing change from 2.6 to 2.7 and Mac bundle builder problems

[Barry Scott]

You did not set PYTHONHOME that effects the code in calculate_path a lot.
Also there is platform specific code in tht code.

Barry


On 28 Dec 2012, at 22:30, Antoine Pitrou solip...@pitrou.net wrote:

 On Fri, 28 Dec 2012 21:39:56 +
 Barry Scott ba...@barrys-emacs.org wrote:
 I'm trying to track down why bundlebuilder no longer works with python 2.7
 to create runnable Mac OS X apps.
 
 I have got as far as seeing that imports of modules are failing.
 
 What I see is that sys.path does not contain all the elements from the
 PYTHONPATH variable.
 
 No matter what I put in PYTHONPATH only the first element is in sys.path.
 
 I can't reproduce under Linux:
 
 $ PYTHONPATH=/x:/y python -Sc import sys; print(sys.path)
 ['', '/x', '/y', '/usr/lib/python27.zip', '/usr/lib64/python2.7/',
 '/usr/lib64/python2.7/plat-linux2', '/usr/lib64/python2.7/lib-tk',
 '/usr/lib64/python2.7/lib-old', '/usr/lib64/python2.7/lib-dynload']
 
 
 Regards
 
 Antoine.
 
 
 ___
 Python-Dev mailing list
 Python-Dev@python.org
 http://mail.python.org/mailman/listinfo/python-dev
 Unsubscribe: 
 http://mail.python.org/mailman/options/python-dev/barry%40barrys-emacs.org
 
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Offer of help: http://bugs.python.org/issue10910

[Barry Scott]

On 24 Jun 2012, at 17:55, Martin v. Löwis mar...@v.loewis.de wrote:

 Is this even an issue for 3.x? ISTM that the C library macros aren't
 used, anyway, so I think this entire section could go from the header
 files.
 
 $ grep isspace 
 /Library/Frameworks/Python.framework/Versions/3.2/include/python3.2m/*.h
 /Library/Frameworks/Python.framework/Versions/3.2/include/python3.2m/pyport.h:#undef
  isspace
 /Library/Frameworks/Python.framework/Versions/3.2/include/python3.2m/pyport.h:#define
  isspace(c) iswspace(btowc(c))
 
 I'm not familiar with pyport.h usage. I do see that it protects the problem 
 lines with:
 #ifdef _PY_PORT_CTYPE_UTF8_ISSUE
 
 I think you missed my point. Python shouldn't be using isspace anymore
 at all, so any work-arounds for certain BSD versions should be outdated
 and can be removed entirely.
 
 Of course, before implementing that solution, one would have to verify
 that this claim (macros not used) is indeed true.

Fine so long as the bad code goes.

 
 So long as that is not defined when C++ is in use no problem.
 
 I'm not so much concerned with compiling with C++, but care about a
 potential cleanup of the headers.

I hope you are not claiming that it is o.k for python to ignore c++ developers!

I hope that it is rasonable to state that the pyhon api can be used from C++ 
without fear or the need for hacky work arounds.

 
 For 2.7, things are more difficult.
 
 This is where a fix is required. Is there going to be another 2.7 release to 
 deliver a fix in?
 
 Yes, there will be more 2.7 bugfix releases. If a fix is too intrusive
 or too hacky, it might be that the bug must stay unfixed, though.

It seems that the only reason for the problem in the header is to detect an 
unexpected use of isspace and friends. I cannot see why you could not at a 
minimum remove when C++ compiler is used. I suspect C users could rightly be 
unset at a C api being broken after Python.h is included.

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

[Python-Dev] Offer of help: http://bugs.python.org/issue10910

[Barry Scott]

I see that issue 10910 needs a reviewer for a patch.

I know the python code and C++ and offer to review
any patches to fix this issue.

Having updated Xcode on my Mac I'm having to code
workarounds for this issue.

My understanding is that you cannot define
ispace, toupper etc as macros in C++ environment.
These are defined as functions in C++.

The minimum patch would #ifdef out the offending
lines in byte_methods.h and pyport.h if compiling
for C++.

I'm going to be releasing a PyCXX release to work around
this issue.

Barry

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

Re: [Python-Dev] Offer of help: http://bugs.python.org/issue10910

[Barry Scott]

On 24 Jun 2012, at 14:29, Martin v. Löwis wrote:

 On 24.06.2012 14:52, Barry Scott wrote:
 I see that issue 10910 needs a reviewer for a patch.
 
 I know the python code and C++ and offer to review
 any patches to fix this issue.
 
 Is this even an issue for 3.x? ISTM that the C library macros aren't
 used, anyway, so I think this entire section could go from the header
 files.

 $ grep isspace 
/Library/Frameworks/Python.framework/Versions/3.2/include/python3.2m/*.h
/Library/Frameworks/Python.framework/Versions/3.2/include/python3.2m/pyport.h:#undef
 isspace
/Library/Frameworks/Python.framework/Versions/3.2/include/python3.2m/pyport.h:#define
 isspace(c) iswspace(btowc(c))

I'm not familiar with pyport.h usage. I do see that it protects the problem 
lines with:
#ifdef _PY_PORT_CTYPE_UTF8_ISSUE

So long as that is not defined when C++ is in use no problem.

 
 For 2.7, things are more difficult.

This is where a fix is required. Is there going to be another 2.7 release to 
deliver a fix in?

Barry

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

Re: [Python-Dev] Why does Mac OS X python share site-packages with apple python?

[Barry Scott]

Just to follow up. With Robin's help over in wxPython land I have
given Robin a patch to wxPython to fix the site-packages issue.

Barry

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

[Python-Dev] Why does Mac OS X python share site-packages with apple python?

[Barry Scott]

On my Mac OS X 10.7.3 System I have lots of python kits installed for 
developing extensions.

I'll just noticed that Python.org 2.7.2 uses the sames site-packages folder 
with Apple's
2.7.1.

Since extensions compiled against Apple's 2.7.1 segv when used by python.org's 
2.7.2
this is at least unfortunate.

Here is the what is in sys.path for both versions. Notice 
/Library/Python/2.7/site-packages
is in both.

$ /usr/bin/python -c 'import sys,pprint; pprint.pprint( sys.path )'
['',
 '/usr/local/lib/wxPython-unicode-2.8.12.1/lib/python2.7/site-packages',
 
'/usr/local/lib/wxPython-unicode-2.8.12.1/lib/python2.7/site-packages/wx-2.8-mac-unicode',
 '/System/Library/Frameworks/Python.framework/Versions/2.7/lib/python27.zip',
 '/System/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7',
 
'/System/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/plat-darwin',
 
'/System/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/plat-mac',
 
'/System/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/plat-mac/lib-scriptpackages',
 '/System/Library/Frameworks/Python.framework/Versions/2.7/Extras/lib/python',
 
'/System/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/lib-tk',
 
'/System/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/lib-old',
 
'/System/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/lib-dynload',
 
'/System/Library/Frameworks/Python.framework/Versions/2.7/Extras/lib/python/PyObjC',
 '/Library/Python/2.7/site-packages',
 '/usr/local/lib/wxPython-unicode-2.8.12.1/lib/python2.7']

$ /usr/local/bin/python2.7 -c 'import sys,pprint; pprint.pprint( sys.path )'
['',
 '/usr/local/lib/wxPython-unicode-2.8.12.1/lib/python2.7/site-packages',
 
'/usr/local/lib/wxPython-unicode-2.8.12.1/lib/python2.7/site-packages/wx-2.8-mac-unicode',
 '/usr/local/lib/wxPython-unicode-2.8.12.1/lib/python2.7',
 '/Library/Python/2.7/site-packages',
 '/Library/Frameworks/Python.framework/Versions/2.7/lib/python27.zip',
 '/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7',
 '/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/plat-darwin',
 '/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/plat-mac',
 
'/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/plat-mac/lib-scriptpackages',
 '/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/lib-tk',
 '/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/lib-old',
 '/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/lib-dynload',
 
'/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages']

Barry

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

Re: [Python-Dev] Why does Mac OS X python share site-packages with apple python?

[Barry Scott]

On 3 Mar 2012, at 21:57, Ned Deily wrote:

 In article 5a0e2490-a743-4729-a752-d94524ea9...@barrys-emacs.org,
 Barry Scott ba...@barrys-emacs.org wrote:
 On my Mac OS X 10.7.3 System I have lots of python kits installed for 
 developing extensions.
 
 I'll just noticed that Python.org 2.7.2 uses the sames site-packages folder 
 with Apple's
 2.7.1.
 
 Since extensions compiled against Apple's 2.7.1 segv when used by 
 python.org's 2.7.2
 this is at least unfortunate.
 
 Here is the what is in sys.path for both versions. Notice 
 /Library/Python/2.7/site-packages
 is in both.
 
 That directory is in the default sys.path for both the Apple-supplied 
 Python 2.7 in Lion and for the python.org Python 2.7's but that doesn't 
 mean both versions use the same site-packages directory:
 
 $ /usr/bin/python2.7 -c import distutils.sysconfig; \
print(distutils.sysconfig.get_python_lib())
 /Library/Python/2.7/site-packages
 
 $ /usr/local/bin/python2.7 -c import distutils.sysconfig; \
print(distutils.sysconfig.get_python_lib())
 /Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-pack
 ages
 
 That means that, by default, packages installed by Distutils-based 
 installs (setup.py, easy_install, pip, et al) will be installed to the 
 corresponding directory for each version.


 
 The python.org OS X Pythons (and built-from-source framework builds) add 
 the Apple-specific directory to the search path in order to allow 
 sharing of installed third-party packages between the two.  The feature 
 was added in 2.7 and 3.1+ and tracked in Issue4865 
 (http://bugs.python.org/issue4865).  Please open a new issue on the 
 tracker if you have examples of how this is causing problems.  Thanks.
 

Yes I have a example that SEGV, pysvn details of kit location in bug report.
I take it that any .so will crash as well. Only .py can be shared.

http://bugs.python.org/issue14188

Look at the order of the sys.path the apple python site-packages
hides the python.org site-packages. If the shared folder was after
the python.org then imports could be made to work.

Barry

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

Re: [Python-Dev] PyCObject_AsVoidPtr removed from python 3.2 - is this documented?

[Barry Scott]

On 9 Mar 2011, at 06:50, Georg Brandl wrote:

 On 08.03.2011 23:47, Martin v. Löwis wrote:
 I think everything here is as it should be. People who really cared
 about forwards compatibility could have known, but factually, most
 people don't care enough. Those then learn for the first time that
 some feature was deprecated after it is actually removed. They then
 ask why it is removed, and somebody will tell them.
 
 I was not aware I could turn on deprecation warning for use of the C API.
 How can I do that?
 
 Not sure that you can. When I said could have known, I meant by 
 reading the documentation.
 
 Well, it looks like the CObject functions actually emitted
 PendingDeprecationWarnings when used:
 
 http://hg.python.org/cpython/file/16f8f359db9c/Objects/cobject.c#l12

I changed my testing code for PyCXX to run python -W default and did
indeed get a nice message:

Demo/Python3/test_simple.py:1: PendingDeprecationWarning: The CObject API is 
deprecated as of Python 3.1.  Please convert to using the Capsule API.

Thanks for the info. I'm going to run PyCXX like this for all future release 
testing.

Barry

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

Re: [Python-Dev] PyCObject_AsVoidPtr removed from python 3.2 - is this documented?

[Barry Scott]

On 7 Mar 2011, at 09:33, Martin v. Löwis wrote:

 Am 07.03.2011 10:14, schrieb Nick Coghlan:
 On Mon, Mar 7, 2011 at 6:36 PM, John Arbash Meinel
 j...@arbash-meinel.com  wrote:
 
 Especially since, AIUI, deprecations are suppressed by default now.
 
 True, but developers are expected to run their tests with them enabled.
 
 I think everything here is as it should be. People who really cared
 about forwards compatibility could have known, but factually, most
 people don't care enough. Those then learn for the first time that
 some feature was deprecated after it is actually removed. They then
 ask why it is removed, and somebody will tell them.

I was not aware I could turn on deprecation warning for use of the C API.
How can I do that?

 The OP is actually wrong that this isn't documented in what's new;
 there is an item about it in the porting to 3.2 section.

O.k. I see that now. I searched for the API call that vanished and came up
empty. I did not think to search for cobject or read the porting section.

BTW the link on http://www.python.org/download/releases/3.2/
to what's new points to the 3.3a0 whats new page.

Barry

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

Re: [Python-Dev] What does the m mean for the Mac OS X include folder?

[Barry Scott]

On 7 Mar 2011, at 01:46, Ned Deily wrote:

 In article 5ab965c9-7d5f-41b6-a5e9-2b881e92a...@barrys-emacs.org,
 Barry Scott ba...@barrys-emacs.org wrote:
 There is a break with convention for the include folder name:
 
 /Library/Frameworks/Python.framework/Versions/3.2/include/python3.2m/
 
 What does the m mean?
 
 The m means that the Python was configured and built with pymalloc.
 
 This change was introduced by Issue9807 deriving configuration 
 information for different builds with the same prefix which is an 
 adjunct to PEP 3149 ABI version tagged .so files.  As described in the 
 PEP, the idea is to allow the installation of multiple build variants on 
 one system, for instance, a set of debug shared libraries (with flag 
 d) alongside the normal optimized libraries.  This was extended in 
 Issue9807 to cover the corresponding Include files.   On current Debian 
 installs of python3.2, for instance, one sees:
 
 $ ls -ld /usr/include/python3.2*
 lrwxrwxrwx [...] /usr/include/python3.2 - python3.2mu
 drwxr-xr-x [...] /usr/include/python3.2mu
 
 (u means wide-unicode.)
 
 For OS X framework builds, the unversioned convenience link is not 
 created:
 
 $ cd /Library/Frameworks/Python.framework/Versions/3.2
 $ ls -l
 lrwxr-xr-x [...] Headers@ - include/python3.2m
 -r-xrwxr-x [...] Python*
 drwxrwxr-x [...] Resources/
 drwxrwxr-x [...] bin/
 drwxrwxr-x [...] include/
 drwxrwxr-x [...] lib/
 drwxrwxr-x [...] share/
 $ ls -ld ./include/python3.2*
 drwxrwxr-x [...] ./include/python3.2m/
 
 Perhaps it should.  And the implications of the multiple build variants 
 feature for OS X frameworks build have probably not yet been fully 
 considered.  However, there are now multiple ways to find the proper 
 location of the include files and library files, both in 
 platform-independent and framework-specific (note the Headers link) 
 ways.  And they all seem to produce the correct results.
 
 $ bin/python3.2
 import sysconfig
 sysconfig.get_path('include')
 '/Library/Frameworks/Python.framework/Versions/3.2-release_10.6/include/p
 ython3.2m'
 ^D
 $ bin/python3-config --include
 -I/Library/Frameworks/Python.framework/Versions/3.2-release_10.6/include/
 python3.2m 
 -I/Library/Frameworks/Python.framework/Versions/3.2-release_10.6/include/
 python3.2m
 
 (So good you get it twice in the same line.)
 
 In some ways, this issue falls into a bit of a black hole.  For other 
 Unix-y platforms, the PSF (python.org) does not provide binaries or 
 installers so issues like installation locations are to some extent at 
 the discretion of the various distributors (Debian, Fedora, et al).  For 
 Mac OS X and Windows, the PSF also plays the role of binaries/installer 
 distributor so some things specific to those installers may need to be 
 documented outside of the standard Python documentation set (or properly 
 noted).
 
 Feel free to open an issue if you feel something should be changed (code 
 or documentation).

Thanks for this full explanation.

I can use the Headers link and that will make it possible to do the same thing
for compiling against all versions from 2.4 to 3.2.

Barry


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

[Python-Dev] What does the m mean for the Mac OS X include folder?

[Barry Scott]

There is a break with convention for the include folder name:

/Library/Frameworks/Python.framework/Versions/3.2/include/python3.2m/

What does the m mean?

Barry

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

[Python-Dev] PyCObject_AsVoidPtr removed from python 3.2 - is this documented?

[Barry Scott]

I see that PyCObject_AsVoidPtr has been removed from python 3.2.
The 3.2 docs do not seem to explain this has happened and what
to replace it with.

I searched the 3.2 docs and failed to find PyCObject_AsVoidPtr.
I looked at the whats new page and the API PEP. Did I miss
where this is documented?

Because I have a contribution to PyCXX to use a new API that
replaces PyCObject_AsVoidPtr I'm not stuck. But I'm sure I'm not 
the only python user that uses PyCObject_AsVoidPtr and will
need a point to the replacement.

Barry

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

Re: [Python-Dev] Add const to python API - issue 6952

[Barry Scott]

On 22 Oct 2009, at 20:31, Barry Scott wrote:



On 21 Oct 2009, at 06:15, Martin v. Löwis wrote:

I suggest following POSIX's lead and omitted the const in these  
cases.


Ah... Yes I see this in strstr for example.



Thanks, that sounds reasonable.



This is basically what I have done in the patch I hope.
I have updated the patch to include a comment explaining
why output  param is char ** and the need for a cast.


Have I address the issues sufficiently for the patch to be accepted?

Should I go ahead a create the python 3 version of the patch?

Barry

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

Re: [Python-Dev] Add const to python API - issue 6952

[Barry Scott]

On 21 Oct 2009, at 06:15, Martin v. Löwis wrote:

I suggest following POSIX's lead and omitted the const in these  
cases.


Ah... Yes I see this in strstr for example.



Thanks, that sounds reasonable.



This is basically what I have done in the patch I hope.
I have updated the patch to include a comment explaining
why output  param is char ** and the need for a cast.

Barry

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

Re: [Python-Dev] Add const to python API - issue 6952

[Barry Scott]

On 20 Oct 2009, at 04:35, Martin v. Löwis wrote:


The patch I developed for comment only adds const to the input
parameters and used casts to
allow output parameters to stay without the const.


What specific APIs are you talking about here?


Checking my patch I have two functions that need to
have output params changed to const to avoid casting.

PyOS_strtoul- ptr
PyLong_FromString   - pend

Barry

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

[Python-Dev] Add const to python API - issue 6952

[Barry Scott]

http://bugs.python.org/issue6952

Martin v. Löwis suggested that solutions to this issue should be  
discussed here.


My goal is to avoid compiler warning and the need to cast to remove  
const when

calling the python API.

For example I see compiler messages like this on Mac OS X Snow Leopard  
g++ reports:


example.cxx:633: warning: deprecated conversion from string constant  
to ‘char*’


The patch I developed for comment only adds const to the input  
parameters and used casts to

allow output parameters to stay without the const.

This is because adding the const to the input params will not break  
existing code, but
adding const to output parameters may well require code changes for  
users of the Python

API.

What is the best approach to this problem that will be acceptable?

Barry

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

Re: [Python-Dev] transitioning from % to {} formatting

[Barry Scott]

On 1 Oct 2009, at 10:37, M.-A. Lemburg wrote:


Eric Smith wrote:

Martin v. Löwis wrote:

Steven Bethard wrote:
There's a lot of code already out there (in the standard library  
and

other places) that uses %-style formatting, when in Python 3.0 we
should be encouraging {}-style formatting.


I don't agree that we should do that. I see nothing wrong with using
% substitution.


I agree with Martin.

Both approaches have their ups and downs, but forcing users to move
from %-formatting to .format()-formatting will just frustrate them:
having to convert several thousand such (working) uses in their code
with absolutely no benefit simply doesn't look like a good way to
spend your time.


I agree you cannot force the move to {} format. There are programs that
expose the %(name)s in user interfaces for customisation.



In addition to the code changes, such a move would also render
existing translations of the %-formatted string templates useless.


Speaking of translation support has xgettext been updated to support {}?
It is a life saver to have xgettext report that This %s and %s is not
translatable.

Barry

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

Re: [Python-Dev] PEP 3144 review.

[Barry Scott]

On 14 Sep 2009, at 17:44, Peter Moody wrote:


Folks, Guido,

I believe PEP 3144 is ready for your review.  When you get a chance,
can you take a look/make a pronouncement?




 x=ipaddr.IPv4Network( '192.168.1.1/240.255.0.0' )
 x
IPv4Network('192.168.1.1/16')

You can decide on which bug this shows.

1) parse must raise exception on bad input
2) repr does not show input

Barry

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

Re: [Python-Dev] Python 2.7 Mac universal builds seem broken on trunk

[Barry Scott]

On 27 Sep 2009, at 03:12, Ned Deily wrote:


In article 90a90a3c-e037-4fca-95d2-a46a5c6dd...@barrys-emacs.org,
Barry Scott ba...@barrys-emacs.org wrote:
I'm working with http://svn.python.org/projects/python/trunk on Mac  
OS

X 10.6.1
using Apples xcode gcc 4.2.1.

When I run the following commands:

./configure --enable-framework --with-universal-archs=32-bit | tee
build.config.log
make clean all | tee build.make.log

I end up with a x86_64 Python image.

No matter what I use for archs its always the same.

I would expect to see -arch arg to GCC but it is not there.

export CFLAG=-arch i386


I should have used CFLAGS...



did not work either.

Am I doing something wrong or is this broken on trunk?


You need to add the enable-universalsdk parameter to configure:

 ... --enable-universalsdk=/Developer/SDKs/MacOSX10.6.sdk


Thanks that worked with the 10.5 sdk.



Be aware, though, that universal build support on 10.6 is a bit of a
work in progress as there are still some interesting unexplained
universal build issues when building on Snow Leopard (see, for  
instance,

the comments in http://bugs.python.org/issue6957).  At the moment, the
focus is on getting 2.6.3 out the door and the standard installer for
that will be built on 10.5.


O.k.

Barry

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

[Python-Dev] Python 2.7 Mac universal builds seem broken on trunk

[Barry Scott]

I'm working with http://svn.python.org/projects/python/trunk on Mac OS  
X 10.6.1

using Apples xcode gcc 4.2.1.

When I run the following commands:

	./configure --enable-framework --with-universal-archs=32-bit | tee  
build.config.log

make clean all | tee build.make.log

I end up with a x86_64 Python image.

No matter what I use for archs its always the same.

I would expect to see -arch arg to GCC but it is not there.

export CFLAG=-arch i386

did not work either.

Am I doing something wrong or is this broken on trunk?

Barry

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

Re: [Python-Dev] PEP 383: Non-decodable Bytes in System Character Interfaces

[Barry Scott]

On 30 Apr 2009, at 05:52, Martin v. Löwis wrote:


How do get a printable unicode version of these path strings if they
contain none unicode data?


Define printable. One way would be to use a regular expression,
replacing all codes in a certain range with a question mark.


What I mean by printable is that the string must be valid unicode
that I can print to a UTF-8 console or place as text in a UTF-8
web page.

I think your PEP gives me a string that will not encode to
valid UTF-8 that the outside of python world likes. Did I get this
point wrong?





I'm guessing that an app has to understand that filenames come in  
two forms
unicode and bytes if its not utf-8 data. Why not simply return  
string if

its valid utf-8 otherwise return bytes?


That would have been an alternative solution, and the one that 2.x  
uses

for listdir. People didn't like it.


In our application we are running fedora with the assumption that the
filenames are UTF-8. When Windows systems FTP files to our system
the files are in CP-1251(?) and not valid UTF-8.

What we have to do is detect these non UTF-8 filename and get the
users to rename them.

Having an algorithm that says if its a string no problem, if its
a byte deal with the exceptions seems simple.

How do I do this detection with the PEP proposal?
Do I end up using the byte interface and doing the utf-8 decode
myself?

Barry

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

Re: [Python-Dev] PEP 383: Non-decodable Bytes in System Character Interfaces

[Barry Scott]

On 30 Apr 2009, at 21:06, Martin v. Löwis wrote:

How do get a printable unicode version of these path strings if  
they

contain none unicode data?


Define printable. One way would be to use a regular expression,
replacing all codes in a certain range with a question mark.


What I mean by printable is that the string must be valid unicode
that I can print to a UTF-8 console or place as text in a UTF-8
web page.

I think your PEP gives me a string that will not encode to
valid UTF-8 that the outside of python world likes. Did I get this
point wrong?


You are right. However, if your *only* requirement is that it should
be printable, then this is fairly underspecified. One way to get
a printable string would be this function

def printable_string(unprintable):
 return 


Ha ha! Indeed this works, but I would have to try to turn enough of the
string into a reasonable hint at the name of the file so the user can
some chance of know what is being reported.




This will always return a printable version of the input string...


In our application we are running fedora with the assumption that the
filenames are UTF-8. When Windows systems FTP files to our system
the files are in CP-1251(?) and not valid UTF-8.


That would be a bug in your FTP server, no? If you want all file names
to be UTF-8, then your FTP server should arrange for that.


Not a bug its the lack of a feature. We use ProFTPd that has just  
implemented
what is required. I forget the exact details - they are at work - when  
the ftp client
asks for the FEAT of the ftp server the server can say use UTF-8.  
Supporting

that in the server was apparently none-trivia.






Having an algorithm that says if its a string no problem, if its
a byte deal with the exceptions seems simple.

How do I do this detection with the PEP proposal?
Do I end up using the byte interface and doing the utf-8 decode
myself?


No, you should encode using the strict error handler, with the
locale encoding. If the file name encodes successfully, it's correct,
otherwise, it's broken.


O.k. I understand.

Barry

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

Re: [Python-Dev] PEP 383: Non-decodable Bytes in System Character Interfaces

[Barry Scott]

On 22 Apr 2009, at 07:50, Martin v. Löwis wrote:



If the locale's encoding is UTF-8, the file system encoding is set to
a new encoding utf-8b. The UTF-8b codec decodes non-decodable bytes
(which must be = 0x80) into half surrogate codes U+DC80..U+DCFF.



Forgive me if this has been covered. I've been reading this thread for  
a long time

and still have a 100 odd replies to go...

How do get a printable unicode version of these path strings if they  
contain

none unicode data?

I'm guessing that an app has to understand that filenames come in two  
forms
unicode and bytes if its not utf-8 data. Why not simply return string  
if its valid
utf-8 otherwise return bytes? Then in the app you check for the type  
for the object,

string or byte and deal with reporting errors appropriately.

Barry

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

Re: [Python-Dev] bundlebuilder broken in 2.6

[Barry Scott]

On 17 Jan 2009, at 20:08, Ned Deily wrote:

In article 7043cb7c-18f4-4e16-ae0c-cda6ba311...@barrys-emacs.org,
Barry Scott ba...@barrys-emacs.org wrote:


It seems that the packaging of Mac Python 2.6 is missing at least one
file
that is critical to the operation of bundlebuilder.py.

I've logged the issue as http://bugs.python.org/issue4937.


I've noted a workaround in the tracker: just copy the file from an  
older

version of Python.   It's a simple xml plist and I don't think its
contents are all that critical anyway.


I figured the contents are not not important as the files from 2.5 and  
2.4

talk of alpha this that and the other.




While the build should be fixed for 2.6+ (I'll send a patch), note  
that

bundlebuilder is gone in 3.0.


What is the replacement for bundlebuilder for 3.0? Lack of
bundlebuilder becomes a serious porting problem for me.
I deliver pysvn WOrkbench as a bundle to simplify installation
by my users.

Barry

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

[Python-Dev] bundlebuilder broken in 2.6

[Barry Scott]

It seems that the packaging of Mac Python 2.6 is missing at least one  
file

that is critical to the operation of bundlebuilder.py.

I've logged the issue as http://bugs.python.org/issue4937.

Barry

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

Re: [Python-Dev] Python 3 - Mac Installer?

[Barry Scott]

On 26 Dec 2008, at 23:30, Benjamin Peterson wrote:

On Fri, Dec 26, 2008 at 2:55 AM, Mark Summerfield  
l...@qtrac.plus.com wrote:

Hi,

Just wondered if/when there'd be a Mac installer for Python 3?


I think there should be one eventually. Unfortunately, the 3.x build
process is not ironed out. If somebody wants to make a patch which
makes the build script in Mac/BuildScript/ work, I'd be very happy. :)


Since I've been building 3.0 for a while now I looked at the script.

build-install.py seems to have been half converted to py 3.0.
Going full 3.0 was not hard but then there is the problem of
the imports.

Python 3.0 does not have MacOS or Carbon modules.

Seems that there are two ways to go.

Put back the Carbon and MacOS modules into 3.0.
Use Python 2 to build the python 3 package.

Barry

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

Re: [Python-Dev] porting pycxx and pysvn to python 3.0 hit a problem

[Barry Scott]

On Oct 5, 2008, at 22:49, Terry Reedy wrote:


Barry Scott wrote:


for key in [pysvn.wc_status_kind.added,
pysvn.wc_status_kind.replaced,
pysvn.wc_status_kind.unversioned]:
print( '2 key', key, key in wc_status_kind_map, cmp( key,  
pysvn.wc_status_kind.unversioned ), hash( key ) )

try:
print( '2 lookup', wc_status_kind_map[ key ] )
except:
print( '2 failed' )



2 key added False 1 -586300914
2 failed
2 key replaced False 1 -586300911
2 failed
2 key unversioned False 0 -586300916
2 failed


Given that p.we.x seems to always return the same object (since the  
hashes, which which appear to be ids, are the same), an __eq__  
method (which gets called in preference to __cmp__), possibly  
inherited, that always return False is the only thing I can think  
of.  (Hence Martin's question, I presume).  I have no idea,  
however, how porting could make that happen.


The type is not derived so the __eq__ cannot be happening.

I guess I need to use gdb and figure out what is going on.

Barry

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

Re: [Python-Dev] porting pycxx and pysvn to python 3.0 hit a problem

[Barry Scott]

On Oct 5, 2008, at 22:49, Terry Reedy wrote:

Given that p.we.x seems to always return the same object (since the  
hashes, which which appear to be ids, are the same), an __eq__  
method (which gets called in preference to __cmp__), possibly  
inherited, that always return False is the only thing I can think  
of.  (Hence Martin's question, I presume).  I have no idea,  
however, how porting could make that happen.


I see no reply from Martin. What was his question?

Barry

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

Re: [Python-Dev] porting pycxx and pysvn to python 3.0 hit a problem

[Barry Scott]

On Oct 5, 2008, at 19:47, Martin v. Löwis wrote:

Why does key in wc_status_kind_wc work when I use an object  
returned

by keys() by not when I use pysvn.wc_status_kind.unversioned?


This is too little detail to come up with an explanation. Do your
objects support __eq__.

Regards,
Martin



I wrote a smaller version of the code that fails and had a session with
gdb.

My object implements tp_compare but lookdict() uses richcompare.
If richcompare is not implemented do_richcompare() falls back to
comparing PyObject * pointers - which is cause of the KeyError
as the objects cmp() eq but have different PyObect * values.

This is a change from V2 python where to be a key implementing
tp_hash and tp_compare is sufficient.

In V3 is it your intention that to be a key you must implement
tp_hash and tp_richcompare? If not I'll raise a bug against
3.0 on this issue.

Barry

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

Re: [Python-Dev] porting pycxx and pysvn to python 3.0 hit a problem

[Barry Scott]

On Oct 7, 2008, at 23:31, Martin v. Löwis wrote:


In V3 is it your intention that to be a key you must implement
tp_hash and tp_richcompare? If not I'll raise a bug against
3.0 on this issue.


I believe that cmp/tp_compare are being phased out, although
I think there was a heavy debate about this.


Given the problems I am seeing with tp_compare I'd advise
that you get rid of it for 3.0. The half hearted support is worst
then no support. At least if you remove tp_compare it forces
a porter to implement tp_richcompare.



In any case, I think you really need to implement tp_richcompare.


I've added support already in PyCXX. I'll now implement
tp_richcompare for pysvn and document this in my PyCXX
porting guide.

Barry

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

[Python-Dev] porting pycxx and pysvn to python 3.0 hit a problem

[Barry Scott]

I have a version of PyCXX ported to python 3.0 rc1 and its passing  
its tests.

I'm porting pysvn to python 3.0 rc1 and hit an odd problem.

Given this dict:

wc_status_kind_map = {
pysvn.wc_status_kind.added: 'A',
pysvn.wc_status_kind.replaced: 'R',
pysvn.wc_status_kind.unversioned: '?',
}

This fails:

wc_status_kind_map[ pysvn.wc_status_kind.unversioned ]

With:

KeyError: wc_status_kind.unversioned

Clearly I have a bug in the implementation of pysvn.wc_status_kind and
could do with some suggestions on what to check please.

I've assumed that if my objects support tp_hash and tp_compare
they can be used as keys to a dictionary. My test scripts shows
hash() and cmp() working.

Why does key in wc_status_kind_wc work when I use an object returned
by keys() by not when I use pysvn.wc_status_kind.unversioned?

Barry


- a.py 
import pysvn

wc_status_kind_map = {
pysvn.wc_status_kind.replaced: 'R',
pysvn.wc_status_kind.unversioned: 'U',
}

print( 'hash wc_status_kind', hash( wc_status_kind ) )
print( 'hash replace', hash( pysvn.wc_status_kind.replaced ) )
print( 'hash unversioned', hash( pysvn.wc_status_kind.unversioned ) )

print( 'cmp unversioned, unversioned', cmp 
( pysvn.wc_status_kind.unversioned, pysvn.wc_status_kind.unversioned ) )
print( 'cmp unversioned, replaced', cmp 
( pysvn.wc_status_kind.unversioned, pysvn.wc_status_kind.replaced ) )
print( 'cmp replaced, unversioned', cmp 
( pysvn.wc_status_kind.replaced, pysvn.wc_status_kind.unversioned ) )


for key in wc_status_kind_map.keys():
print( '1 key', key, key in wc_status_kind_map, cmp( key,  
pysvn.wc_status_kind.unversioned ), hash( key ) )

try:
print( '1 lookup', wc_status_kind_map[ key ] )
except:
print( '1 failed' )

for key in [pysvn.wc_status_kind.added,
pysvn.wc_status_kind.replaced,
pysvn.wc_status_kind.unversioned]:
print( '2 key', key, key in wc_status_kind_map, cmp( key,  
pysvn.wc_status_kind.unversioned ), hash( key ) )

try:
print( '2 lookup', wc_status_kind_map[ key ] )
except:
print( '2 failed' )

print( wc_status_kind_map[ pysvn.wc_status_kind.unversioned ] )

 Output ---
$ python3.0 a.py
hash wc_status_kind -586300918
hash replace -586300911
hash unversioned -586300916
cmp unversioned, unversioned 0
cmp unversioned, replaced -1
cmp replaced, unversioned 1
1 key replaced True 1 -586300911
1 lookup R
1 key unversioned True 0 -586300916
1 lookup U
2 key added False 1 -586300914
2 failed
2 key replaced False 1 -586300911
2 failed
2 key unversioned False 0 -586300916
2 failed
Traceback (most recent call last):
  File a.py, line 32, in module
print( wc_status_kind_map[ pysvn.wc_status_kind.unversioned ] )
KeyError: wc_status_kind.unversioned

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

Re: [Python-Dev] Should we help pythonmac.org?

[Barry Scott]

On Aug 18, 2008, at 22:06, Bob Ippolito wrote:


The major difference between the packages on macports and
pythonmac.org is that macports is their own distro of nearly
everything, akin to installing a copy of FreeBSD over top of Mac OS X.
pythonmac.org contains packages that are self-contained and don't have
a whole new set of libraries to install (in the cases where they do
require libraries, they link them in statically for the most part).



Theses comments are from my point of view as a developer
for end users on the Mac.

For my pysvn project I release kits for all the python versions

* Apple python 2.3 powerpc
* Apple python 2.4 intel
* MacPython 2.4.x powerpc
* MacPython 2.5.x powerpc and intel

And in the future I intend to support:
* 2.6b3 framework build
* 3.0b3 framework build

These are all framework builds and they are totally isolated from  
each other.


And I release pysvn as DMG kits as well.

For pysvn workbench I use the wxWidgets released DMG kits.
And create a application using python module bundlebuilder.

Whatever you do should point to a framework build including  
bundelbuilder
which is installed using a Mac installer. Which is the status quo so  
far.


Barry

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

Re: [Python-Dev] String concatenation

[Barry Scott]

On Aug 3, 2008, at 19:12, Stavros Korokithakis wrote:

Hmm, thanks, although I don't see why it was rejected, since it  
seems to me that by using the addition operator or triple-quoting  
all the use cases would become clearer and not significantly harder  
to write, while the (often silent) errors would not happen any more.


I use this feature all the time in preference to triple quote strings  
to allow the indenting structure to be preserved.


def I_like_this():
s = (a multi line\n
   that keeps the indent of the function)
return

def I_do_not_like_this():
s = '''a multi line
that break the indent of the function
return


Barry

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

Re: [Python-Dev] 3.0 C API to decode bytes into unicode?

[Barry Scott]

On Aug 1, 2008, at 14:30, M.-A. Lemburg wrote:


On 2008-08-01 15:06, Barry Scott wrote:
I cannot see how I implement decode() for bytes objects using the  
C API

for PyCXX library,
I'd assuming that I should find a PyBytes_Decode function but  
cannot find it

in beta 2.
What is the preferred way to do this?


PyUnicode_FromEncodedObject() should to the trick.


Thanks thats what I've use.

Barry

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

[Python-Dev] 3.0 C API to decode bytes into unicode?

[Barry Scott]

I cannot see how I implement decode() for bytes objects using the C API
for PyCXX library,

I'd assuming that I should find a PyBytes_Decode function but cannot  
find it

in beta 2.

What is the preferred way to do this?

Barry

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

Re: [Python-Dev] Any PEP about 2.6 - 3000 code transition?

[Barry Scott]

On Jul 21, 2008, at 22:37, Lennart Regebro wrote:


On Mon, Jul 21, 2008 at 20:16, Brett Cannon [EMAIL PROTECTED] wrote:

But waiting until all the betas have gone out totally defeats the
purpose of the betas!


I agree. Writing an actual *guide* can wait, but documenting the
differences with code examples is a work that can start now, and I
agree that it would be great if this would start now.

But writing a guide might not be a good idea until we know what the
changes are, and if the API is changing quickly now we don't. :-)


I'm working on  getting a version of PyCXX working with Python 3.0.
The lack of any docs outside of the header files is making this a slow
process.

I think its a mistake to expect a serious beta test of extensions
when you have no guide to the changes in the C API.

If you had a guide then diff it between releases would be a guide to
what need fixing up going from beta to beta to rc.

Oh and I'm not going to try and make a version of PyCXX that works
on 2.x and 3.x as the changes are too fundamental.

Barry

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

[Python-Dev] Web site type: Python 2.6b2 Released: 18-Jun-2008

[Barry Scott]

I think you mean july.

Barry

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

Re: [Python-Dev] Any PEP about 2.6 - 3000 code transition?

[Barry Scott]

See http://code.google.com/p/python-incompatibility/source/checkout

Barry



On Jul 19, 2008, at 03:25, Jesus Cea wrote:


-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Lennart Regebro wrote:
| On Sun, May 25, 2008 at 6:25 AM, Jesus Cea [EMAIL PROTECTED] wrote:
| Since I need to port bsddb3 to py3k, what I need to know?. Is any
| *updated* document out there?.
|
| No, but there is a not yet complete, but quite updated set of  
examples.

|
| http://code.google.com/p/python-incompatibility/
|
| This is a collection of code snippets that will show code that does
| work under 2.x but not under 3.x, and the 3.x way of doing it (as  
well

| as a way that works under both 2.6 and 3.0, in applicable cases).
|
| There is no tests for changes in the C-API, if you (or somebody  
else)

| would like to add that (or any other tests) that would be very
| appreciated!

I can't checkout the code. What username/password must I use?.

- --
Jesus Cea Avion _/_/  _/_/_/_/_/_/
[EMAIL PROTECTED] - http://www.jcea.es/ _/_/_/_/  _/_/_/_/   
_/_/

jabber / xmpp:[EMAIL PROTECTED] _/_/_/_/  _/_/_/_/_/
.  _/_/  _/_/_/_/  _/_/  _/_/
Things are not so easy  _/_/  _/_/_/_/  _/_/_/_/  _/_/
My name is Dump, Core Dump   _/_/_/_/_/_/  _/_/  _/_/
El amor es poner tu felicidad en la felicidad de otro - Leibniz
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.8 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iQCVAwUBSIFQnZlgi5GaxT1NAQL3LQP/ZxblxpJwZAQ9qIUXHAZpFlmK86y7UPfT
DX707wR1YMOujiNazE2NuJSVCVkbbOlc1G2dxTAqDm7FAThkjuIeO74ijueUeFdN
p6LP2dS5pHH8h8G9bUfDynGCjRQ4t1TUblksQgPDtrYiXlzIBqYL1qkHRf72w2c3
fyuZWBpaH0w=
=nnN4
-END PGP SIGNATURE-
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: http://mail.python.org/mailman/options/python-dev/barry 
%40barrys-emacs.org




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

Re: [Python-Dev] Problem building module against Mac Python 2.4 and Python 2.5

[Barry Scott]

 Use an absolute path to the library rather than -framework.

 That is, add '/Library/Frameworks/Python.framework/Versions/2.4/ 
 Python' to the link command instead of '-framework Python'.

Thanks  I'll update my builds to do that.


 Or use distutils!

 That's definitely advisable anyway, that way you'll automaticly get  
 the right flags to compile and link the extension :-)

I call distutils to get some information for CFLAGS and include dirs.  
I'll look at what I get back for
libs and update my build script.

All my code is C++ and in the past distutils lacked C++ support so I  
could not use it and have develoer
my own solution to the build problem.

Does distutils work for C++ code these days?

Barry

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

[Python-Dev] Problem building module against Mac Python 2.4 and Python 2.5

[Barry Scott]

This may be down to my lack of knowledge of Mac OS X development.

I want to build my python extension for Python 2.3, 2.4 and 2.5 on  
the same Mac.
Build Python 2.3 and Python 2.4 has been working well for a long  
time. But
after I installed Python 2.5 it seems that I can no longer link a  
against Python 2.4
without changing sym link /Library/Frameworks/Python.framework/ 
Versions/Current
to point at the one I want to build against.

The problem did not arise with Python 2.3 and Python 2.4 because  
Python 2.3
is in /System/Library and Python 2.4 is in /LIbrary. Telling ld which  
framework
folder to look in allows both to be linked against.

Is there a way to force ld to use a particular version of the python  
framework or do
I have to change the symlink each time I build against a different  
version?

This type of problem does not happen on Windows or Unix by design.

Barry

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

Re: [Python-Dev] Maybe we should have a C++ extension for testing...

[Barry Scott]

On Sep 13, 2006, at 18:46, [EMAIL PROTECTED] wrote:


 Building Python with C and then linking in extensions written in or  
 wrapped
 with C++ can present problems, at least in some situations.  I  
 don't know if
 it's kosher to build that way, but folks do.  We're bumping into such
 problems at work using Solaris 10 and Python 2.4 (building  
 matplotlib, which
 is largely written in C++), and it appears others have similar  
 problems:

 http://bugs.opensolaris.org/bugdatabase/view_bug.do?bug_id=6395191
 http://mail.python.org/pipermail/patches/2005-June/017820.html
 http://mail.python.org/pipermail/python-bugs-list/2005-November/ 
 030900.html

 I attached a comment to the third item yesterday (even though it was
 closed).

 One of our C++ gurus (that's definitely not me!) patched the Python  
 source
 to include wchar.h at the top of Python.h.  That seems to have  
 solved our
 problems, but seems to be a symptomatic fix.  I got to thinking,  
 should we
 a) encourage people to compile Python with a C++ compiler if most/ 
 all of
 their extensions are written in C++ anyway (does that even work if  
 one or
 more extensions are written in C?), or b) should the standard  
 distribution
 maybe include a toy extension written in C++ whose sole purpose is  
 to test
 for cross-language problems?

Mixing of C and C++ code is fully supported by the compilers and  
linkers.
There is no need to compile the python core as C++ code, indeed if you
did only C++ extension could use it!

In the distent past  there had been problems with some
unix distributions linking python in such a way that C++ code would not
initialise. The major distributions seem to have sort these problems  
out.
But clearly Solaris has a problem.

It would be worth finding out out why it was necessary to include  
wchar.h
to fix the problems. If you do add a C++ test extension it will need  
to do what
ever it was that wchar.h fixes.

 From what I can remember attempts to use std::cout would fail and I  
think
static object initialisation would fail. The test code would need to  
do all these
things and verify they are working.

Barry (PyCXX cxx.sourceforge.net)



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

[Python-Dev] What windows tool chain do I need for python 2.5 extensions?

[Barry Scott]

I have the tool chains to build extensions against your binary python  
2.2, 2.3 and 2.4 on windows.

What are the tool chain requirements for building extensions against  
python 2.5 on windows?

Barry


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

Re: [Python-Dev] epoll implementation

[Barry Scott]

On May 27, 2006, at 04:59, Alex Martelli wrote:


 I believe it's: kqueue on FreeBSD (for recent-enough versions
 thereof), otherwise epoll where available and nonbuggy, otherwise
 poll ditto, otherwise select -- that's roughly what Twisted uses for

kqueue is not always faster. It depends on your application. The number
of FDs and the fd values affect the point that kqueue wins over select.

For a few FDs with low values select was always faster in my apps.

Barry

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

Re: [Python-Dev] Why are contexts also managers? (wasr45544 -peps/trunk/pep-0343.txt)

[Barry Scott]

On Apr 24, 2006, at 03:49, Nick Coghlan wrote:

 Just van Rossum wrote:
 Baptiste Carvello wrote:

 Terry Reedy a écrit :
 So I propose that the context maker be called just that: 'context
 maker'. That should pretty clearly not be the context that manages
 the block execution.

 +1 for context maker. In fact, after reading the begining of the
 thread, I came up with the very same idea.

 Or maybe context factory?

Yes its a factory. That is traditionally that you call a function  
that makes objects isn't it?

 That would be fine if we used __call__ to retrieve the context  
 manager - but
 factory is too tightly bound to factory function in my mind.

__call__ may or may not implement a factory, that is up to my design  
to decide.
__context__ is always  a factory because that is the interface that  
with mandates.
factory function is one way to implement a factory so yes its tightly  
bound,
but that not a reason to reject factory.

 From what I've read on this list this is all there is to it:

with EXPR:
block

with needs a context. If the EXPR object has a __context__ method
it is a factory that will make a suitable context for the EXPR object
otherwise EXPR is the context.

that context must have __enter__ and __exit__ methods to operate
the with protocol.

I haven't learn about decorators so I've no comment on why you need
them as well as the special method names. But the docs should tell
me why.

Barry

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

[Python-Dev] Build extensions for windows python 2.4 what are the compiler rules?

[Barry Scott]

I see that, as expected, windows python 2.4 was built with MSVC 7.1 
rather then msvc 6.0.

It seems that I can build extensions with msvc 6.0 that work with the 
python 2.4 windows
binary kit.

Is this safe?
I recall warning a while ago about mixing msvc 6.0 and msvc 7.1 runtime 
DLL's. Is this
an issue with python 2.4?

I'm also surprised that the python 2.4 source kit only mentions MSVC 
6.0 and not the
compiler that you actually built python 2.4 with.

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

Re: [Python-Dev] Build extensions for windows python 2.4 what are the compiler rules?

[Barry Scott]

On Dec 23, 2004, at 23:12, Martin v. Löwis wrote:
Barry Scott wrote:
It seems that I can build extensions with msvc 6.0 that work with the 
python 2.4 windows
binary kit.
Is this safe?
No, it isn't. This emerges as a Python 2.4 FAQ.
I recall warning a while ago about mixing msvc 6.0 and msvc 7.1 
runtime DLL's. Is this
an issue with python 2.4?
Yes, it is.
I'm also surprised that the python 2.4 source kit only mentions MSVC 
6.0 and not the compiler that you actually built python 2.4 with.
Why do you say that? PCbuild/readme.txt starts with
I recursive grep'ed and missed this ref. However I did read this in 
README.TXT:

 Building on non-UNIX systems
 
 For Windows (2000/NT/ME/98/95), assuming you have MS VC++ 6.0, the
 project files are in PCbuild, the workspace is pcbuild.dsw.  See
 PCbuild\readme.txt for detailed instructions.
Which says that PCbuild/readme.txt is about VC++ 6.0
Building Python using VC++ 7.1
-
This directory is used to build Python for Win32 platforms, e.g. 
Windows
95, 98 and NT.  It requires Microsoft Visual C++ 7.1
(a.k.a. Visual Studio .NET 2003).
(For other Windows platforms and compilers, see ../PC/readme.txt.)

Regards,
Martin
Barry
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com