[Python-Dev] Is it possible to view tokenizer output?

[Jack]

Hi, I'm just getting into the CPython codebase just for fun, and I've 
just started messing around with the tokenizer and the grammar. I was 
wondering, is there a way to just print out the results of the tokenizer 
(as in just the stream of tokens it generates) in a human readable 
format? It would be really helpful for debugging. Hope the question's 
not too basic.


Cheers.

___
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/2ZTZBAN5H2ET2IB7EXTKD27R5T6QVHZB/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Is it possible to view tokenizer output?

[Jack]

Thanks! I didn't even know about that module. Does this take into 
account your local changes to the tokenizer, though? I've added a new 
token type to Grammar/Tokens, and some code to tokenizer.c to return 
that token type in appropriate circumstances. I've stepped through the 
tokenizer in the debugger, so I /think /it's working. When I run -m 
tokenize as you suggest, I don't see my custom token type.


The devguide mentions that "|Lib/tokenize.py| needs changes to match 
changes to the tokenizer.", so I'm guessing I would have to manually 
repeat my changes in tokenize.py to see them, right? But what I want to 
see is what tokenizer.c is producing when my newly built Python binary 
actually reads a file.


On 30/05/2022 00:09, Jean Abou Samra wrote:



Le 30/05/2022 à 00:59, Jack a écrit :
Hi, I'm just getting into the CPython codebase just for fun, and I've 
just started messing around with the tokenizer and the grammar. I was 
wondering, is there a way to just print out the results of the 
tokenizer (as in just the stream of tokens it generates) in a human 
readable format? It would be really helpful for debugging. Hope the 
question's not too basic.


python -m tokenize file.py

?

See https://docs.python.org/3/library/tokenize.html#command-line-usage

Cheers,
Jean

___
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/ZCG44GZJH4FWPC66TI7GNLYZTHGLQ6NM/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Is it possible to view tokenizer output?

[Jack]

Well, I just stuck a print statement in _PyTokenizer_Get() and it's done 
the job for me, right now.


Thanks,

Jack

On 30/05/2022 00:36, Eric V. Smith wrote:

python -m tokenize < file-to-parse.py

See the comment at the top of tokenize.py. IIRC, it re-implements the 
tokenizer, it does not call the one used for python code.


Eric

On 5/29/2022 6:59 PM, Jack wrote:
Hi, I'm just getting into the CPython codebase just for fun, and I've 
just started messing around with the tokenizer and the grammar. I was 
wondering, is there a way to just print out the results of the 
tokenizer (as in just the stream of tokens it generates) in a human 
readable format? It would be really helpful for debugging. Hope the 
question's not too basic.


Cheers.

___
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/2ZTZBAN5H2ET2IB7EXTKD27R5T6QVHZB/

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/PLOALW2GXI3MHWEEA6L2KDLGHZDP2NC6/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Is it possible to view tokenizer output?

[Jack]

Hi Pablo, could you clarify please? Is that on the main branch, or would 
you be willing to share the code?


On 30/05/2022 16:23, Pablo Galindo Salgado wrote:
There is no *public* one but there is a private one accesible from 
Python I added for testing purposes.


On Mon, 30 May 2022, 15:17 Victor Stinner,  wrote:

On Mon, May 30, 2022 at 1:40 AM Eric V. Smith 
wrote:
> python -m tokenize < file-to-parse.py
>
> See the comment at the top of tokenize.py. IIRC, it
re-implements the
> tokenizer, it does not call the one used for python code.

Ah right, I would be surprised that there would be a public Python API
to get the tokenizer output, since there is no public C API for that
:-)

I just removed  header file since it was never usable outside
Python C internals: there is no public C API to just run the tokenizer
and gets its output.

Victor
___
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/CT3YSWSPMJ5DLUCVBX3AAPRWOUOXYWEL/
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/D3EMINLPE6TXEENR27LOVNN7TTYM2GNE/
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-Dev] Type hints -- a mediocre programmer's reaction

[Jack Diederich]

Twelve years ago a wise man said to me "I suggest that you also propose a
new name for the resulting language"

I talked with many of you at PyCon about the costs of PEP 484. There are
plenty of people who have done a fine job promoting the benefits.

* It is not optional. Please stop saying that. The people promoting it
would prefer that everyone use it. If it is approved it will be optional in
the way that PEP8 is optional. If I'm reading your annotated code it is
certainly /not/ optional that I understand the annotations.

* Uploading stubs for other people's code is a terrible idea. Who do I
contact when I update the interface to my library? The random Joe who
"helped" by uploading annotations three months ago and then quit the
internet? I don't even want to think about people maliciously adding stubs
to PyPI.

* The cognitive load is very high. The average function signature will
double in length. This is not a small cost and telling me it is "optional"
to pretend that every other word on the line doesn't exist is a farce.

* Every company's style guide is about to get much longer. That in itself
is an indicator that this is a MAJOR language change and not just some
"optional" add-on.

* People will screw it up. The same people who can't be trusted to program
without type annotations are also going to be *writing* those type
annotations.

* Teaching python is about to get much less attractive. It will not be
optional for teachers to say "just pretend all this stuff over here doesn't
exist"

* "No new syntax" is a lie. Or rather a red herring. There are lots of new
things it will be required to know and just because the compiler doesn't
have to change doesn't mean the language isn't undergoing a major change.

If this wasn't in a PEP and it wasn't going to ship in the stdlib very few
people would use it. If you told everyone they had to install a different
python implementation they wouldn't. This is much worse than that - it is
Python4 hidden away inside a PEP.

There are many fine languages that have sophisticated type systems. And
many bondage & discipline languages that make you type things three times
to make really really sure you meant to type that. If you find those other
languages appealing I invite you to go use them instead.

-Jack

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

[Python-Dev] Re: Heads up: `make` in Doc now creates a venv

[Jack DeVries]

What do you think about an environment variable?

USE_VENV=false make html

Maybe we can use a variable with a more explicit name so people can keep it
in their environments if they wish?

On Fri, Aug 6, 2021 at 7:19 AM Miro Hrončok  wrote:

> On 06. 08. 21 12:21, Łukasz Langa wrote:
> >
> >> On 4 Aug 2021, at 11:48, Miro Hrončok  wrote:
> >>
> >> On 04. 08. 21 11:28, Petr Viktorin wrote:
> >>> Hi,
> >>> A recent change "make html" in the Doc directory create a venv if one
> wasn't there before. If you don't want to download sphinx and other
> dependencies from PyPI, you'll need to adjust your workflow.
> >>> If you already have all the dependencies, the following command (in
> the CPython directory, not Doc) will build docs for you:
> >>>   sphinx-build Doc Doc/build/
> >>> The issue that added this is: https://bugs.python.org/issue44756
> >>
> >> For what it's worth, I think that:
> >>
> >> - changes in the workflow should be discussed first
> >> - changes like this should not happen this late in the release cycle
> >> - a documented/supported way to build the docs with make without venv
> should
> >>exist (currently, running `mkdir venv` before `make ...` kinda works)
> >
> > Sorry for the disruption, I approved the change. I didn't realize
> skipping the `venv` altogether was a viable build option and I've been
> making releases with docs for over two years now. For me this change was
> mostly a matter of convenience.
> >
> > If the current state is undesirable for downstream distributors, I can
> revert `make build` being explicitly dependent on `make venv`.
>
> The current state is OK-ish but fragile. There is a way to skip the venv
> creation by creating an empty venv directory. However, it is undocumented
> and
> implementation-dependent (read: it is a hack). If we have a supported way
> to do
> this, I wouldn't might the default changed (although, honestly I don't
> think
> this should have been backported to 3.9 at this point).
>
> > Regardless of that, for future build-related changes I'll make sure to
> loop more people in.
>
> Thanks.
>
> --
> 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/CTVVAVYOHQKNB4S36G36YP3SFXKBKIQE/
> 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/NES6TWPFVTRL72XK773OLDP6VBECYB6N/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] New __main__.rst

[Jack DeVries]

There have been a series of requests to enhance the current __main__.rst
document :

bpo-17359 
bpo-24632 
bpo-39452 

So, I rewrote it! I went ahead and hosted it on my website for you all to
easily take a look: https://jackdevries.com/pydoc__main__/library/__main__.html

Of course, you can go directly to the GitHub PR instead:
https://github.com/python/cpython/pull/26883

For reference, here is a link to the current document:
https://docs.python.org/3/library/__main__.html

This is a major change, so I'm thankful for anyone who can take the time to
review it. I am a new cpython contributor, so advice for how to push this ahead
is also welcome. For example, should I break this up into multiple PRs at this
point?

Thank you all!
___
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/BSAS3N73T5ILYCQQ6JQBGHL5RPFHNOPL/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: New __main__.rst

[Jack DeVries]

Huh, distributive pronouns... you learn something every day:

https://en.wikipedia.org/wiki/Distributive_pronoun

I think I'm just going to change the word "each" to "both", though,
because I don't like how "Each of these mechanisms is..." reads. Thank
you for the catch @MRAB.


On Tue, Aug 10, 2021 at 05:14:10PM +0100, MRAB wrote:
> On 2021-08-10 03:14, Jack DeVries wrote:
> > There have been a series of requests to enhance the current __main__.rst
> > document <https://docs.python.org/3/library/__main__.html>:
> > 
> > bpo-17359 <https://bugs.python.org/issue17359>
> > bpo-24632 <https://bugs.python.org/issue24632>
> > bpo-39452 <https://bugs.python.org/issue39452>
> > 
> > So, I rewrote it! I went ahead and hosted it on my website for you all to
> > easily take a look: 
> > https://jackdevries.com/pydoc__main__/library/__main__.html
> > 
> > Of course, you can go directly to the GitHub PR instead:
> > https://github.com/python/cpython/pull/26883
> > 
> > For reference, here is a link to the current document:
> > https://docs.python.org/3/library/__main__.html
> > 
> > This is a major change, so I'm thankful for anyone who can take the time to
> > review it. I am a new cpython contributor, so advice for how to push this 
> > ahead
> > is also welcome. For example, should I break this up into multiple PRs at 
> > this
> > point?
> > 
> Point of grammar: "Each of these mechanisms are related" should be "Each of
> these mechanisms is related". You might think that it's "are" because it
> follows "mechanisms", but it's "Each (something) is".
> ___
> 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/NRV2NHID465FGCMPHHLT7KS6WEOFSOU3/
> 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/WIRGGAYNSD2YTX3WQRZL6JO7E3UMH6N3/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Should we try to get a complete draft of What's New by b1?

[Jack DeVries]

On a broader note, how does the deployment pipeline for documentation work?
It seems to me that for branches that are in pre-release (3.10) or active
development (3.11), the documentation should be continuously deployed,
while deployment of changes to earlier documentation should follow minor
releases for those versions.

Sorry this question is naive -- I don't know how it works currently. Would
it be possible to set something like this up?

On Thu, Aug 12, 2021, 3:02 AM Serhiy Storchaka  wrote:

> 11.08.21 21:35, Brett Cannon пише:
> > So my question is whether we want to push to be more diligent about
> > updating What's New by b1 so people can provide feedback during the
> > betas beyond just reporting breaking changes?
>
> I think that What's New should be updated as soon as possible,
> immediately after the addition of the feature. I started contributing to
> Python after reading What's New for one of early alphas of 3.3 (and the
> questioned feature was changed later). There were other examples, when
> features were advertised in alphas, but were changed after getting a
> feedback before betas.
>
> ___
> 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/RQQ2QEV3OKCMAJGHLB52SKXLAIL7BB34/
> 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/V7E6UQPHXQSQZQSDFBLOGTS4AGGGPLJF/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Should we try to get a complete draft of What's New by b1?

[Jack DeVries]

> If you look at the version picker on docs.python.org you will see that we
already have the docs for 3.10 and 3.11 available. I don't know if they are
updated per release right now or per commit.

I understand that they are available options. To clarify my suggestion, I
think that 3.11 should be updated on a per commit basis (continuous
deployment); including updating the what's new pages continuously. If that
is not done already, I'm curious if it is been looked into before, and
whether it might be possible to set things up like this?

I was originally thinking that 3.10 documentation should be deployed
continuously as well, but on further thought I realized that that would put
the beta releases out of sync with the documentation which obviously does
not make any sense. Maybe we could add a new tab to the version picker
called 3.10/HEAD or similar. Maybe there's another solution?

Either way, continuous deployment of documentation for 3.11 (or whatever
version cpython/HEAD is at any given time) seems like it should be the norm
if it isn't already. If that is already the case, I'm sorry for the noise!
I still think that continuous deployment of documentation on the head of
the beta or alpha release branches is worth considering, maybe with a
different label on docs.python.org like "cpython/3.10@latest" or similar.


On Thu, Aug 12, 2021, 12:46 PM Brett Cannon  wrote:

>
>
> On Thu, Aug 12, 2021 at 6:04 AM Jack DeVries 
> wrote:
>
>> On a broader note, how does the deployment pipeline for documentation
>> work? It seems to me that for branches that are in pre-release (3.10) or
>> active development (3.11), the documentation should be continuously
>> deployed, while deployment of changes to earlier documentation should
>> follow minor releases for those versions.
>>
>> Sorry this question is naive -- I don't know how it works currently.
>> Would it be possible to set something like this up?
>>
>
> If you look at the version picker on docs.python.org you will see that we
> already have the docs for 3.10 and 3.11 available. I don't know if they are
> updated per release right now or per commit.
>
> -Brett
>
>
>>
>> On Thu, Aug 12, 2021, 3:02 AM Serhiy Storchaka 
>> wrote:
>>
>>> 11.08.21 21:35, Brett Cannon пише:
>>> > So my question is whether we want to push to be more diligent about
>>> > updating What's New by b1 so people can provide feedback during the
>>> > betas beyond just reporting breaking changes?
>>>
>>> I think that What's New should be updated as soon as possible,
>>> immediately after the addition of the feature. I started contributing to
>>> Python after reading What's New for one of early alphas of 3.3 (and the
>>> questioned feature was changed later). There were other examples, when
>>> features were advertised in alphas, but were changed after getting a
>>> feedback before betas.
>>>
>>> ___
>>> 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/RQQ2QEV3OKCMAJGHLB52SKXLAIL7BB34/
>>> 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/V7E6UQPHXQSQZQSDFBLOGTS4AGGGPLJF/
>> 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/HKYS5D5KHXAQEAMX5ZKF6UXFVG26ELZF/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Worried about Python release schedule and lack of stable C-API

[jack . jansen]

I’m getting increasingly worried about the future of Python, and those worries 
have been exacerbated by the new yearly release rhythm, and the lack of a 
stable C-API that is full enough to entice extension writers to use it.

PyPI packages and wheels are targeted to specific Python versions, which means 
that any project that depends on some of the larger extension packages (of 
which there are many, and many of which are must-have for many projects) now 
start lagging Python versions by years, because somewhere deep down in the 
dependency graph there is something that is still stuck at Python 3.8 (for 
example). I fully understand that 3.8 is good enough for the developers of that 
package, and that they have more pressing things to do than porting to 3.9 or 
3.10, but it now keeps any project or package that depends on their software on 
3.8 as well.

And I also fully understand that some other developer who creates a new package 
that is essential to my application only targets the current Python release, or 
maybe one release back, but now if I need both the new package and and older 
one I’m up the well-known creek without a paddle.

Building packages from source has become pretty much impossible nowadays, 
especially if your project is multi-platform and needs to interface to specific 
hardware, and you want to do the right thing with CI/CD builds and all that. On 
Linux/MacOS you have a chance when you try to specify all the dependencies for 
third party libraries and what not, but on Windows you’re dead in the water. 
And that is assuming you have the time and are smart enough to back port the 
new package to the old Python release, or the old package to the new Python 
release (and for the latter there’s probably a good reason why the developers 
haven’t done so already). Before you know it you have to install a couple of 
graphics card APIs for some obscure AI feature used by something you’ve never 
heard of, Cython for something else, and obscure vendor libraries for something 
else again.

I think we really need to come up with some scheme whereby extension packages 
become more long-lived than a single Python release...
--
Jack Jansen, , http://www.cwi.nl/~jack
If I can't dance I don't want to be part of your revolution -- Emma Goldman



___
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/7ALUHJBJCZGFGXHK6TTDDR3ST4YVSAWR/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Worried about Python release schedule and lack of stable C-API

[jack . jansen]

> On 26 Sep 2021, at 05:49, Nathaniel Smith  wrote:
> 
> On Sat, Sep 25, 2021 at 5:40 PM  wrote:
>> PyPI packages and wheels are targeted to specific Python versions, which 
>> means that any project that depends on some of the larger extension packages 
>> (of which there are many, and many of which are must-have for many projects) 
>> now start lagging Python versions by years, because somewhere deep down in 
>> the dependency graph there is something that is still stuck at Python 3.8 
>> (for example).
> 
> Can you give some examples of the packages you're thinking of, that
> are prominent/must-have and stuck on years-old Pythons?


Open3D is an example. Will finally move to Python 3.9 some time the coming 
month. Its dependency graph contains about 70 other packages.

In this specific case, the underlying problem was that TensorFlow was stuck at 
3.8. The TensorFlow codebase got ported in November 2020, then released early 
2021. Then Open3D included the new Tensorflow (plus whatever else needed to be 
adapted) in their codebase in May. They’re now going through their release 
schedule, and their 0.14 release should be up on PyPI soon. 

--
Jack Jansen, , http://www.cwi.nl/~jack
If I can't dance I don't want to be part of your revolution -- Emma Goldman

___
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/PJYUB2R4VB7H4UBFQ6464OAKFAXBSRJQ/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Worried about Python release schedule and lack of stable C-API

[jack . jansen]

> On 26 Sep 2021, at 04:09, MRAB  wrote:
> 
> On 2021-09-26 00:14, jack.jan...@cwi.nl wrote:
>> I think we really need to come up with some scheme whereby extension 
>> packages become more long-lived than a single Python release...
> You mean, something like the Python ABI (PEP 384, Stable Application Binary 
> Interface)?

And Steven D”Aprano also mentioned the stable ABI.

The problem with the stable ABI is that very few developers are targeting it. 
I’m not sure why not, whether it has to do with incompleteness of the ABI, or 
with issues targeting it easily and your builds and then having pip/PyPI do the 
right things with wheels and all that. I’ve been on the capi-sig mailing list 
since its inception in 2007, but the discussions are really going over my head. 
I don’t understand what the problems are that keep people from targeting the 
stable ABI (or the various other attempts at standardising extensions over 
Python versions).


> On 26 Sep 2021, at 06:21, Steven D'Aprano  wrote:
> 
> Do you have a reason to think that it is in danger in some way? Some 
> factor that didn't apply equally in 2001 and 2011 as it does in 2021?

Yes, very much so. Wheels.

Before we had wheels there were very few packages that were distributed in 
binary form, the NumPy family and the various GUI toolkits are the only ones 
that come to mind, and they had very active developer communities that tracked 
Python releases.

Wheels are absolutely wonderful, but the downside is that everyone has come to 
depend on them. Before wheels, extension modules were often optional, in that 
many packages would provide their basic functionality in pure Python, and then 
have some performance-enhancing or functionality-extending optional extension 
modules. Wheels have obviated the need for that. So now everything depends on 
extension modules (and on external packages that depend on extension modules, 
and so on).
--
Jack Jansen, , http://www.cwi.nl/~jack
If I can't dance I don't want to be part of your revolution -- Emma Goldman


___
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/O5WTFG5WER7PALCYFCDJLP4VWYUWMAPS/
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-Dev] PEP 526 ready for review: Syntax for Variable and Attribute Annotations

[Jack Diederich]

+0. We should try and be consistent even if this is a thing I don't
want. And trust me, I don't!

That said, as long as pro-mypy people are willing to make everyone else pay
a mypy reading tax for code let's try and reduce the cognitive burden.

* Duplicate type annotations should be a syntax error.
  Duplicate annotations aren't possible in functions so that wasn't an
issue in 484. 526 makes some things syntax errors and some things runtime
errors (for good reason -- function bodies aren't evaluated right away).
Double-annotating a variable is something we can figure out at compile time
and doing the double annotating is non-sensical so we should error on it
because we can.

*  Dissallowing annotations on global and nonlocal
  Agreed, allowing it would be confusing because it would either be a
re-definition or a hard to read annotation-at-a-distance.

* Where __annotations__ live
  It is strange to allow modules.__annotations__ and
MyClass.__annotations__ but not myfunc.__annotations__ (or more in line
with existing function implementations a myfunc.__code__.co_annotations).
If we know enough from the syntax parse to have func.__code__.co_varnames
be known then we should try to do that with annotations.  Let's raise a
SyntaxError for function body annotations that conflict with same-named
variables that are annotated in the function signature as well.

I did C++ for years before I did Python and wrote C++ in many languages
(including Python). So ideally I'm -1000 on all this stuff for cultural
reasons -- if you let a C++ person add types they will for false comfort.
But again, I'm +0 on this specific proposal because we have already gone
down the garden path.

-Jack


On Tue, Aug 30, 2016 at 9:00 PM, Steven D'Aprano 
wrote:

> On Tue, Aug 30, 2016 at 02:20:26PM -0700, Guido van Rossum wrote:
> > I'm happy to present PEP 526 for your collective review:
>
> Are you hoping to get this in before 3.6 beta? Because I'm not sure I
> can give this much attention before then, but I really want to.
>
>
> --
> Steve
> ___
> Python-Dev mailing list
> Python-Dev@python.org
> https://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe: https://mail.python.org/mailman/options/python-dev/
> jackdied%40gmail.com
>
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PEP 526 ready for review: Syntax for Variable and Attribute Annotations

[Jack Diederich]

On Tue, Aug 30, 2016 at 11:03 PM, Guido van Rossum  wrote:

> On Tue, Aug 30, 2016 at 7:44 PM, Jack Diederich 
> wrote:
> > +0. We should try and be consistent even if this is a thing I don't want.
> > And trust me, I don't!
>
> No problem. You won't have to!
>
>
Yes! I don't have to want it, it is here!


> > That said, as long as pro-mypy people are willing to make everyone else
> pay
> > a mypy reading tax for code let's try and reduce the cognitive burden.
> >
> > * Duplicate type annotations should be a syntax error.
> >   Duplicate annotations aren't possible in functions so that wasn't an
> issue
> > in 484. 526 makes some things syntax errors and some things runtime
> errors
> > (for good reason -- function bodies aren't evaluated right away).
> > Double-annotating a variable is something we can figure out at compile
> time
> > and doing the double annotating is non-sensical so we should error on it
> > because we can.
>
> Actually I'm not so sure that double-annotating is always nonsensical.
> In the mypy tracker we're seeing some requests for type *inference*
> that allows a variable to be given another type later, e.g.
>
> x = 'abc'
> test_func(x)
> x = 42
> another_test_func(x)
>
> Maybe there's a use for explicit annotations too. I would rather not
> get in the way of letting type checkers decide such semantics.
>
>
Other languages (including rpython) don't allow rebinding types (or
sometimes even re-assignment to same type). We are going for clarity [and
bondage, and discipline]. If we are doing types let's do types like other
people do. I think *disallowing* redefining the type is general to
enforcing types. +1 on being consistent with other langs. If plain
redoubling of types is allowed I'm OK "i: int = 0" doesn't summon horrors
when said three times into a mirror. But we can't always know what "int"
evaluates to so I'd just disallow it.


> > *  Dissallowing annotations on global and nonlocal
> >   Agreed, allowing it would be confusing because it would either be a
> > re-definition or a hard to read annotation-at-a-distance.
> >
> > * Where __annotations__ live
> >   It is strange to allow modules.__annotations__ and
> MyClass.__annotations__
> > but not myfunc.__annotations__ (or more in line with existing function
> > implementations a myfunc.__code__.co_annotations). If we know enough
> from
> > the syntax parse to have func.__code__.co_varnames be known then we
> should
> > try to do that with annotations.  Let's raise a SyntaxError for function
> > body annotations that conflict with same-named variables that are
> annotated
> > in the function signature as well.
>
> But myfunc.__annotations__ already exists -- PEP 3107 puts the
> signature annotations there. The problem with co_annotations is that
> annotations are evaluated (they can be quite complex expressions, e.g.
> Optional[Tuple[int, int, some_mod.SomeClass]]), while co_varnames is
> just a list of strings. And code objects must be immutable. The issue
> with rejecting duplicate annotations so sternly is the same as for the
> previous bullet.
>
>
If we disallow re-assignment of types as a syntax error then the conflict
with myfunc.__annotations__ goes away for vars that share a name with the
function arguments. The fact that variables with types can't be known until
the function body executes a particular line is .. I'm not sure how to deal
with that. For modules and classes you can assert that the body at the top
indent level has been executed. For functions you can only assert that it
has been parsed. So myfunc.__annotations__ could say that the type has a
definition but only later know what the definition is.

> I did C++ for years before I did Python and wrote C++ in many languages
> > (including Python). So ideally I'm -1000 on all this stuff for cultural
> > reasons -- if you let a C++ person add types they will for false comfort.
> > But again, I'm +0 on this specific proposal because we have already gone
> > down the garden path.
>
> As long as you run mypy the comfort shouldn't be false. (But your
> starting with C++ before Python explains a lot. :-)
>

We've talked about this and we have different relationships with tools. I'm
a monk who thinks using a debugger is an admission of failure; you think
linters are a fine method of dissuading others of sin.
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

[Python-Dev] Re: RFC on Callable Type Syntax

[jack . jansen]

If I can make a wild suggestion: why not create a little language for type 
specifications?

If you look at other programming languages you’ll see that the “type definition 
sub-language” is often completely different from the “execution sub-language”, 
with only some symbols in common and used in vaguely related ways.  `bool 
(*myfuncptr)(int, float*)` uses a completely different set of syntactic rules 
than `rv = (*myfunptr)(*myintptr, &myfloat)`. So with some grains of salt you 
could say that C is comprised of a declarative typing sublanguage and an 
imperative execution sublanguage.

Python typing uses basically a subset of the execution expression syntax as its 
declarative typing language.

What if we created a little language that is clearly flagged, for example as 
t”….” or t’….’? Then we could simply define the typestring language to be 
readable, so you could indeed say t”(int, str) -> bool”. And we could even 
allow escapes (similar to f-strings) so that the previous expression could also 
be specified, if you really wanted to, as t”{typing.Callable[[int, str], bool}”.

Jack

> On 7 Oct 2021, at 18:41, S Pradeep Kumar  wrote:
> 
> Hello all,
> 
> Typing-sig has been discussing user-friendly syntax for the type used to 
> represent callables. [1] Since this affects the Python language syntax, we 
> wanted to get some high-level feedback from you before putting up a detailed 
> PEP.
> 
> TL;DR: We want to propose syntax for Callable types, e.g., `(int, str) -> 
> bool` instead of `typing.Callable[[int, str], bool]`. Questions: 1. Are there 
> concerns we need to keep in mind about such a syntax change? 2. Should we 
> propose syntax for additional features in the same PEP or in a future PEP?
> 
> 
> # Motivation
> 
> Guido has pointed out that `Callable` is one of the most frequently used type 
> forms but has the least readable syntax. For example, say we have a callback 
> `formatter` that accepts a record and a list of permissions:
> 
> ```python
> def print_purchases(
> user,
> formatter,  # <-- callback
> ):
> <...>
> output = formatter(record, permissions)
> print(output)
> ```
> 
> To give it a type, we currently have to write:
> 
> ```python
> from typing import Callable
> 
> def print_purchases(
> user: User,
> formatter: Callable[[PurchaseRecord, List[AuthPermission]], 
> FormattedItem]  # Hard to read.
> ) -> None:
> 
> <...>
> output = formatter(record, permissions)
> print(output)
> ```
> 
> `Callable` can be hard to understand for new users since it doesn't resemble 
> existing function signatures and there can be multiple square brackets. It 
> also requires an import from `typing`, which is inconvenient. Around 40% of 
> the time [2], users just give up on precisely typing the parameters and 
> return type of their callbacks and just leave it as a blank Callable. In 
> other cases, they don't add a type for their callback at all. Both mean that 
> they lose the safety guarantees from typing and leave room for bugs.
> 
> We believe that adding friendly syntax for Callable types will improve 
> readability and encourage users to type their callbacks more precisely. Other 
> modern, gradually-typed languages like TypeScript (JS), Hack (PHP), etc. have 
> special syntax for Callable types.
> 
> (As a precedent, PEP 604 recently added clean, user-friendly syntax for the 
> widely-used `Union` type. Instead of importing `Union` and writing `expr: 
> Union[AddExpr, SubtractExpr], we can just write `expr: AddExpr | 
> SubtractExpr`.)
> 
> 
> # Proposal and Questions
> 
> We have a two-part proposal and questions for you:
> 
> 1. Syntax to replace Callable
> 
> After a lot of discussion, there is strong consensus in typing-sig about 
> adding syntax to replace Callable. So, the above example would be written as:
> ```python
> def print_purchases(
> user: User,
> formatter: (PurchaseRecord, List[AuthPermission]) -> FormattedItem,
> ) -> None:
> 
> <...>
> output = formatter(record, permissions)
> print(output)
> ```
> This feels more natural and succinct. 
> 
> Async callbacks currently need to be written as 
> ```
> from typing import Callable
> 
> async_callback: Callable[[HttpRequest], Awaitable[HttpResponse]]
> ```
> 
> With the new syntax, they would be written as 
> ```
> async_callback: async (HttpRequest) -> HttpResponse
> ```
> which again seems more natural. There is similar syntax for the type of 
> decorators that pass on *args and **kwargs to the decorated function.
> 
> Note that we considered and rejected using a full def-signature syntax like 
> 
> (

[Python-Dev] Suggestion: a little language for type definitions

[jack . jansen]

I posted this suggestion earlier in the callable type syntax discussion, at 
which point it was completely ignored. Possibly because it’s a really stupid 
idea, but let me post it again on the off chance that it isn’t a stupid idea 
but was overlooked. 

> If I can make a wild suggestion: why not create a little language for type 
> specifications?
> 
> If you look at other programming languages you’ll see that the “type 
> definition sub-language” is often completely different from the “execution 
> sub-language”, with only some symbols in common and used in vaguely related 
> ways.  `bool (*myfuncptr)(int, float*)` uses a completely different set of 
> syntactic rules than `rv = (*myfunptr)(*myintptr, &myfloat)`. So with some 
> grains of salt you could say that C is comprised of a declarative typing 
> sublanguage and an imperative execution sublanguage.

And an even better example is Pascal, which uses a set of syntactic constructs 
for typing that are completely different from the execution statement syntax: 
`var a : array[1..10] of real` looks very different from `a[1]`, where C `float 
a[10]` looks pretty similar to `a[10]`.

The next bit of my original email is another wild idea, the previous bit 
doesn’t depend on it really. I can imagine completely different ways of doing a 
typing sublanguage:

> Python typing uses basically a subset of the execution expression syntax as 
> its declarative typing language.
> 
> What if we created a little language that is clearly flagged, for example as 
> t”….” or t’….’? Then we could simply define the typestring language to be 
> readable, so you could indeed say t”(int, str) -> bool”. And we could even 
> allow escapes (similar to f-strings) so that the previous expression could 
> also be specified, if you really wanted to, as t”{typing.Callable[[int, str], 
> bool}”.

--
Jack Jansen, , http://www.cwi.nl/~jack
If I can't dance I don't want to be part of your revolution -- Emma Goldman



___
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/26JB6YIPWXUSTQSXTVSZMUS6FM4RZBJA/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Suggestion: a little language for type definitions

[jack . jansen]

Indeed, there needs to be a way to get back and forth from the little typing 
language to Python and back.

That’s why I suggested the t-string format: in analogy to f-strings you could 
use {expression} constructs in there that would be evaluated in the normal 
Python environment (and syntax).

For the sake of argument lets assume for now that the little language uses
-  a : b to be equivalent to Mapping[a, b]
- [a] to be Sequence[a]
- (a, b) being Tuple[a, b] 
- (a, b) -> c being Callable,
- *a being Iterable[a]
- ?a being Optional[a]

Then your example would become something like

T = TypeVar(’T’)
Data = t’str : [(int, T)]’
Factory = t’(int, *str) -> ?[Data(T)]’

And note that I’m making up the syntax as I’m typing. Maybe it’s much better to 
use keywords (like optional, iterable) in stead of symbols).
--
Jack Jansen, , http://www.cwi.nl/~jack
If I can't dance I don't want to be part of your revolution -- Emma Goldman



> On 8 Jan 2022, at 11:32, Serhiy Storchaka  wrote:
> 
> 08.01.22 01:59, jack.jan...@cwi.nl пише:
>>> If I can make a wild suggestion: why not create a little language for
>>> type specifications?
> 
> We need a way to define aliases. For example, write:
> 
> Data = Mapping[str, Sequence[Tuple[int, T]]]
> Factory = Callable[[int, Iterable[str]], Optional[list[Data[T
> 
> def get_foo_factory(type: str, id: int) -> Factory[Foo]: ...
> 
> instead of
> 
> def get_foo_factory(type: str, id: int) -> Callable[[int,
> Iterable[str]], Optional[list[Mapping[str, Sequence[Tuple[int,
> Foo]]: ...
> 
> ___
> 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/42A5UC246FL2C57WSXP5Y2DANFGTG4PU/
> 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/WAGSHSCI7TULRYM367S2SXWJOVJIHLKK/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Suggestion: a little language for type definitions

[jack . jansen]

On 8 Jan 2022, at 23:05, Skip Montanaro  wrote:

>> ... make sense of what they’re reading.
> Some of us have that problem with type-embellished code now. I'm not sure a 
> little language would be such a bad idea. 🤔 Fortunately, my relationship to 
> the working world allows me to simply ignore explicit typing. 😉

Yeah, that was my take too, until about a year ago.

In the last year I’ve contributed mods to two packages that were rejected 
because I hadn’t provided typing (and black formatting, but that’s a different 
subject). I’ve reluctantly done so. And while I *hated* it because of the 
unreadability I _do_ like the outcome: I changed some of the APIs because they 
were doing things “my way”, but that was really pretty impossible to explain to 
the typing system. The modified APIs are arguably cleaner.

I’m not yet at the point where I’m going to type all the packages and other 
stuff I maintain, but I _am_ contemplating doing it, eventually, maybe, if I 
find the time, procrastination willing, …. 
--
Jack Jansen, , http://www.cwi.nl/~jack
If I can't dance I don't want to be part of your revolution -- Emma Goldman



___
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/52PLPW735QJD235BEKOBCHJREI6MWBRT/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Suggestion: a little language for type definitions

[jack . jansen]

Barry:
> The advantage to users of keeping the languages the same is that readers of 
> your code don’t have to learn two disparate syntaxes to make sense of what 
> they’re reading.  One of Python’s enduring strengths has been its 
> readability. 

Agreed. But if the little language is (a) clearly flagged and (b) has a 
different domain I think this is much less of a problem. I don’t think 
f-strings are seen as a problem, far from it, because they’re clearly flagged. 
That’s why I suggested t-strings. And while from a Python parser point-of-view 
the grammar of current type expressions are the same as the grammar of other 
Python code I think that for human readers this is not the case: there’s a lot 
of square brackets but nothing is being indexed, to name one major readability 
issue...

Stéfane:

> Using the same syntax may have some benefits for language implementors (e.g. 
> less complex grammar to implement), but I don’t really see these benefits for 
> language users.
> 
> As an example, and I don’t know if this has been discussed before, I think a 
> pretty neat syntax construct for optional argument would be (like, for 
> instance, in Kotlin):
> 
> def f(x: int? = None): ...

I introduced the t-strings specifically because I think it would be beneficial 
to have the little language a clearly flagged and have as little interaction 
with “normal” Python as possible. Your example here works fine for Optional, 
and looks pretty understandable if you know C# (or apparently Kotlin), but it 
doesn’t solve all the other problems with readability. And I think you’ll 
quickly run out of constructs once you try to fix more problems if you don’t 
want to clash with existing Python syntax…

--
Jack Jansen, , http://www.cwi.nl/~jack
If I can't dance I don't want to be part of your revolution -- Emma Goldman


___
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/HLHH3VFNA32M2JHJIZ5OSWKHTCZLOJLH/
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-Dev] Tracker cleanup report

[Jack Jansen]

On  16-Feb-2009, at 20:40 , Daniel (ajax) Diniz wrote:


There are about 20 Mac-related, 24 invalid/outdated and four IRIX
issues on the 'will be closed unless someone voices disagreement'
queue, so we have a good chance of totaling a hundred closed issues in
ten days.



I had a cursory look at these issues as they came by, and I didn't see  
any that struck me as still being relevant.

--
Jack Jansen, , http://www.cwi.nl/~jack
If I can't dance I don't want to be part of your revolution -- Emma  
Goldman




___
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] OSError.errno => exception hierarchy?

[Jack diederich]

On Thu, Apr 2, 2009 at 4:25 PM, Benjamin Peterson  wrote:
> 2009/4/2 Gustavo Carneiro :
>> Apologies if this has already been discussed.
>
> I don't believe it has ever been discussed to be implemented.
>
>> Apparently no one has bothered yet to turn OSError + errno into a hierarchy
>> of OSError subclasses, as it should.  What's the problem, no will to do it,
>> or no manpower?
>
> Python doesn't need any more builtin exceptions to clutter the
> namespace. Besides, what's wrong with just checking the errno?

The problem is manpower (this has been no ones itch).  In order to
have a hierarchy of OSError exceptions the underlying code would have
to raise them.  That means diving into all the C code that raises
OSError and cleaning them up.

I'm +1 on the idea but -1 on doing the work myself.

-Jack
___
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] Tools

[Jack diederich]

On Sun, Apr 5, 2009 at 10:50 PM,   wrote:
>    Barry> Someone asked me at Pycon about stripping out Demos and Tools.
>
>    Matthias> +1, but please for 2.7 and 3.1 only.
>
> Is there a list of other demos or tools which should be deleted?  If
> possible the list should be publicized so that people can pick up external
> maintenance if desired.

I liked Brett's (Georg's?) half joking idea at sprints.  Just delete
each subdirectory in a separate commit and then wait to see what
people revert.

-Jack
___
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] Getting information out of the buildbots

[Jack diederich]

I committed some new telnetlib tests yesterday to the trunk and I can
see they are failing on Neal's setup but not what the failures are.
Ideally I like to get the information out of the buildbots but they
all seem to be hanging on stdio tests and quiting out.

Ideas?  TIA,

-Jack
___
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] decorator module in stdlib?

[Jack diederich]

On Wed, Apr 8, 2009 at 12:09 AM, Michele Simionato
 wrote:
> On Tue, Apr 7, 2009 at 11:04 PM, Terry Reedy  wrote:
>>
>> This probably should have gone to the python-ideas list.  In any case, I
>> think it needs to start with a clear offer from Michele (directly or relayed
>> by you) to contribute it to the PSF with the usual conditions.
>
> I have no problem to contribute the module to the PSF and to maintain it.
> I would just prefer to have the ability to change the function signature in
> the core language rather than include in the standard library a clever hack.

Flipping Michele's commit bit (if he wants it) is overdue.  A quick
google doesn't show he refused it in the past, but the same search
shows the things things he did do - including the explication of MRO
in 2.3 (http://www.python.org/download/releases/2.3/mro/).  Plus he's
a softie for decorators, as am I.

-Jack
___
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] slightly inconsistent set/list pop behaviour

[Jack diederich]

On Wed, Apr 8, 2009 at 2:44 AM, Mark Dickinson  wrote:
> On Wed, Apr 8, 2009 at 7:13 AM, John Barham  wrote:
>> If you play around a bit it becomes clear that what set.pop() returns
>> is independent of the insertion order:
>
> It might look like that, but I don't think this is
> true in general (at least, with the current implementation):
>
>>>> foo = set([1, 65537])
>>>> foo.pop()
> 1
>>>> foo = set([65537, 1])
>>>> foo.pop()
> 65537

You wrote a program to find the two smallest ints that would have a
hash collision in the CPython set implementation?  I'm impressed.  And
by impressed I mean frightened.

-Jack
___
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] Google Summer of Code/core Python projects - RFC

[Jack diederich]

On Fri, Apr 10, 2009 at 4:38 PM, C. Titus Brown  wrote:
[megasnip]
> roundup VCS integration / build tools to support core development --
>        a single student proposed both of these and has received some
>        support.  See http://slexy.org/view/s2pFgWxufI for details.

>From the listed webpage I have no idea what he is promising (a
combination of very high level and very low level tasks).  If he is
offering all the same magic for Hg that Trac does for SVN (autolinking
"r2001" text to patches, for example) then I'm +1.  That should be
cake even for a student project.

He says vague things about patches too, but I'm not sure what.  If he
wanted to make that into a 'patchbot' that just applied every patch in
isolation and ran 'make && make test' and posted results in the
tracker I'd be a happy camper.

But maybe those are goals for next year, because I'm not quite sure
what the proposal is.

-Jack
___
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] Needing help to change the grammar

[Jack diederich]

On Fri, Apr 10, 2009 at 9:58 PM, Harry (Thiago Leucz Astrizi)
 wrote:
>
> Hello everybody. My name is Thiago and currently I'm working as a
> teacher in a high school in Brazil. I have plans to offer in the
> school a programming course to the students, but I had some problems
> to find a good langüage. As a Python programmer, I really like the
> language's syntax and I think that Python is very good to teach
> programming. But there's a little problem: the commands and keywords
> are in english and this can be an obstacle to the teenagers that could
> enter in the course.
>
> Because of this, I decided to create a Python version with keywords in
> portuguese and with some modifications in the grammar to be more
> portuguese-like. To this, I'm using Python 3.0.1 source code.

I love the idea (and most recently edited PEP 306) so here are a few
suggestions;

Brazil has many python programmers so you might be able to make quick
progress by asking them for volunteer time.

To bug-hunt your technical problem: try switching the "not is"
operator to include an underscore "not_is."  The python LL(1) grammar
checker works for python but isn't robust, and does miss some grammar
ambiguities.  Making the operator a single word might reveal a bug in
the parser.

Please consider switching your students to 'real' python part way
through the course.  If they want to use the vast amount of python
code on the internet as examples they will need to know the few
English keywords.

Also - most python core developers are not native English speakers and
do OK :)  PyCon speakers are about 25% non-native English speakers and
EuroPython speakers are about the reverse (my rough estimate - I'd
love to see some hard numbers).

Keep up the Good Work,

-Jack
___
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 3003 - Python Language Moratorium

[Jack Diederich]

+1.  There are no compelling language changes on the horizon ("yield
from" is nice but not necessary).  I see the main benefit of a
moratorium as social rather than technical by encouraging people to
work on the lib instead of the language.  Plus, I'd gladly proxy my
vote to any one of the three PEP authors so 3/3 is a no-brainer.

-Jack
___
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] [RELEASED] Python 2.7 alpha 2

[Jack Diederich]

On Mon, Jan 11, 2010 at 7:11 PM, Barry Warsaw  wrote:
> As an example, the one library I've already ported used a metaclass.  I don't
> see any way to specify that the metaclass should be used in a portable way.
> In Python 2.6 it's:
>
> class Foo:
>    __metaclass__ = Meta
>
> and in Python 3 it's:
>
> class Foo(metaclass=Meta):
>
> 2to3 made that pain go away.

[sidebar]
1) the metaclass fixer was a PITA to implement.
2) 95% of __metaclass__ definitions searchable via google code were of
the "__metaclass__ = type" variety.  The 2to3 patch exists only
because of the few other uses.
3) 100% of the module level assignments in public projects were the
"__metaclass__ = type" variety which is why there isn't a fixer for
that.  Also, a fixer would have been really, really ugly (munge every
class definition in this module because there is a top level
assignment).

-Jack
___
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] E3 BEFEHLE

[Jack Diederich]

Good lord, did this make it past other people's spam filters too?  I
especially liked the reference to "REGION -2,0 ; Rlyeh".  Ph'nglui
mglw'nafh Cthulhu R'lyeh wgah'nagl fhtagn to you too sir.

-Jack

2010/1/16 Christian Heimes :
> ERESSEA Lord "evzp24"
> ; TIMESTAMP 1263675732032
> ; Magellan Version 2.0.4 (build 361)
> ; ECHECK -r100 -s -l -w4 -v4.3.2
> LOCALE de
> REGION -2,0 ; Rlyeh
> ; ECheck Lohn 11
> EINHEIT umwc;           Pyrit Eisenbeisser [2,0$]
> // Zwerg: Bergmann
> LERNEN Bergbau
> EINHEIT 4fh4;           Beryllium [2,771$]
> // Halbing: Burgenbau
> LERNEN Armbrustschießen
> EINHEIT zqpv;           Petalit [2,0$]
> // Waffenschmied
> LERNEN Waffenbau
> EINHEIT dt23;           Selenit [1,0$]
> // Halbling: Bergmann
> LERNEN Bergbau
> EINHEIT v5ze;           Steinmetz [2,0$]
> LERNEN Steinbau
> EINHEIT q3vw;           Eisenschürfer [2,0$]
> LERNEN Bergbau
> EINHEIT eph9;           Sediment [3,0$,U250]
> // Zwerg: Steinbau
> MACHEN Stein
> GIB 4kae 36 Stein
> EINHEIT mmhx;           Pferde [2,0$]
> // Pferde
> MACHEN Pferde
> GIB 4kae 11 Pferd
> EINHEIT sm8c;           Transportling [3,0$]
> LERNEN Reiten
> GIB 4kae 3 Pferd
> EINHEIT 4kae;           Wagner [7,0$]
> NACH NW NO
> GIB 4fh4 ALLES Holz
> REGION -3,2 ; Hochplateau von Leng
> ; ECheck Lohn 11
> EINHEIT eqqm;           Schuetzling [4,2059$]
> LERNEN Armbrustschießen
> EINHEIT h8yz;           Axtwache [5,0$]
> // Zwerg: Hiebwaffen
> LERNEN Ausdauer
> EINHEIT c1xk;           Schwertlinge [9,0$]
> // Halbling Schwertkämpfer
> LERNEN Hiebwaffen
> EINHEIT es76;           Maurer [6,0$]
> LERNEN Burgenbau
> EINHEIT cmhv;           Steinsucher [1,0$]
> NACH W
> EINHEIT nzmg;           Eisensucher [1,0$]
> LERNEN Bergbau
> EINHEIT zwfv;           Schützlinge [11,0$]
> LERNEN Armbrustschießen
> REGION -4,2 ; Trockental
> ; ECheck Lohn 11
> EINHEIT ovyv;           Eisenfinder [1,522$]
> // Halbling: besetze Wueste
> LERNEN Burgenbau
> EINHEIT nzqL;           Steinfresser [1,0$]
> LERNEN Steinbau
> REGION -4,1 ; Eryndyn
> ; ECheck Lohn 11
> EINHEIT geoz;           Geode Lapislazuli [1,736$]
> // Zwerg: Magier
> ZAUBERE Stufe 1 "Segen der Erde"
> EINHEIT 6p3f;           Axtmeister [5,0$]
> LERNEN Ausdauer
> EINHEIT ph9e;           Holzfäller [3,0$]
> // Halblinge: Holzfaeller
> LERNEN Holzfällen
> EINHEIT 4uxp;           Schuetzling [6,0$]
> // Halbling Armbrust
> LERNEN Armbrustschießen
> EINHEIT by3t;           Kyanit [4,0$]
> // Halblinge: Holzfaeller
> LERNEN Holzfällen
> EINHEIT jo9p;           Steinsucher [1,0$]
> LERNEN Steinbau
> EINHEIT btd9;           Maurer [4,0$,U250]
> VERLASSEN
> GIB 7i43 ALLES Stein
> GIB 7i43 ALLES Eisen
> GIB 456o 5 Holz
> NACH O
> EINHEIT 456o;           Zimmermeister [2,0$]
> LERNEN Holzfällen
> EINHEIT sven;           Sven Handelson [1,0$]
> LERNEN Wagenbau
> EINHEIT 7i43;           Maurer [8,34$]
> MACHEN Burg 16pi
> REGION -3,1 ; Wald von Arden
> ; ECheck Lohn 12
> EINHEIT geoa;           Geode Amethyst [1,0$]
> // Zauberer
> ZAUBERE Stufe 1 "Segen der Erde"
> @RESERVIEREN 20 Silber
> EINHEIT y574;           Niob [5,1775$]
> // Zwerg: Waffenbau
> LERNEN Waffenbau
> EINHEIT 8gs0;           Werfer [1,0$]
> // Zwerg: Katapult, Hiebwaffen
> LERNEN Katapultbedienung
> EINHEIT apq6;           Werfer [1,0$]
> LERNEN Katapultbedienung
> EINHEIT u699;           Wagner [2,0$]
> LERNEN Wagenbau
> EINHEIT mq0v;           Meisterschmied [2,0$]
> LERNEN Rüstungsbau
> EINHEIT gLyd;           Kies [3,0$]
> // Halbling: Armbrust
> LERNEN Armbrustschießen
> EINHEIT L18v;           Pikiener [4,0$]
> LERNEN Stangenwaffen
> EINHEIT xLw5;           Schuetzling [4,0$]
> LERNEN Armbrustschießen
> // Armbrustschuetzen
> EINHEIT nyv5;           Axtmeister [2,0$]
> // Axtheld
> LERNEN Ausdauer
> EINHEIT dpb6;           Kämpfer [9,0$]
> LERNEN Hiebwaffen
> EINHEIT kseh;           Transportling [2,0$]
> LERNEN Reiten
> GIB mq0v ALLES Stein
> NACH SO
> REGION -4,3 ; Ebene von Yuggoth
> ; ECheck Lohn 11
> EINHEIT efzf;           Selenit [14,0$]
> // Halbling: Stangenwaffen
> LERNEN Stangenwaffen
> EINHEIT dgji;           Baryl [2,719$]
> // Burg + Armbrust
> LERNEN Armbrustschießen
> EINHEIT geom;           Geode Malachit [1,10$]
> // Zauberer
> ZAUBERE Stufe 1 "Segen der Erde"
> @RESERVIEREN 20 Silber
> EINHEIT e5cb;           Zimmerling [8,0$]
> LERNEN Schiffbau
> EINHEIT jvyx;           Maurer [3,0$]
> LERNEN Burgenbau
> EINHEIT y3jj;           Dressur [2,0$]
> // Halbling Dressur
> LERNEN Reiten
> EINHEIT qwkc;     

Re: [Python-Dev] PEP 3146: Merge Unladen Swallow into CPython

[Jack Diederich]

On Wed, Jan 20, 2010 at 5:27 PM, Collin Winter  wrote:
[big snip]
> In order to support hardware and software platforms where LLVM's JIT does not
> work, Unladen Swallow provides a ``./configure --without-llvm`` option. This
> flag carves out any part of Unladen Swallow that depends on LLVM, yielding a
> Python binary that works and passes its tests, but has no performance
> advantages. This configuration is recommended for hardware unsupported by 
> LLVM,
> or systems that care more about memory usage than performance.

Does disabling the LLVM change binary compatibility between modules
targeted at the same version?  At tonight's Boston PIG we had some
binary package maintainers but most people (including myself) only
cared about source compatibility.I assume linux distros care about
binary compatibility _a lot_.

[snip]
> Managing LLVM Releases, C++ API Changes
> ---
> LLVM is released regularly every six months. This means that LLVM may be
> released two or three times during the course of development of a CPython 3.x
> release. Each LLVM release brings newer and more powerful optimizations,
> improved platform support and more sophisticated code generation.

I don't think this will be a problem in practice as long as the
current rules hold - namely that if someone has already committed a
patch that patch wins unless the later commit is clearly better.  That
puts the onus on people working out-of-sight to incorporate the public
mainline.  I'm sure many internal googler's (and Ubuntu'ers, and
whomever's) patches have already been developed on that timeline and
were integrated into the core without remark or incident.

[snip]
> Open Issues
> ===
>
> - *Code review policy for the ``py3k-jit`` branch.* How does the CPython
>  community want us to procede with respect to checkins on the ``py3k-jit``
>  branch? Pre-commit reviews? Post-commit reviews?
>
>  Unladen Swallow has enforced pre-commit reviews in our trunk, but we realize
>  this may lead to long review/checkin cycles in a purely-volunteer
>  organization. We would like a non-Google-affiliated member of the CPython
>  development team to review our work for correctness and compatibility, but we
>  realize this may not be possible for every commit.

As above, I don't think this will be a problem in practice -- how
often do two people work on the same part of the core?  So long as the
current "firstest with with mostest" practice holds for public commits
it doesn't matter what googlers do in private.

I like it,

-Jack
___
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] Rich Comparison recipe wrong?

[Jack Diederich]

On Mon, Jan 25, 2010 at 6:59 AM, Lennart Regebro  wrote:
[snip]
> If class A returns NotImplemented when compared to class B, and class
> B implements the recipe above, then we get infinite recursion, because
>
> 1. A() < B() will call A.__lt__(B) which will return NotImplemented.
> 2. which will mean that Python calls B.__ge__(A)
> 3. Which B implements by doing A < B
> 4. Start over at 1.

A small correction;  For the purposes of NotImplemented the opposite
of __lt__ is __gt__ because if A < B then B > A.  The pairs are ('==',
'!='), ('<', '>'), ('<=', '>=').

-Jack
___
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] Patch to telnetlib.py

[Jack Diederich]

On Sat, Mar 13, 2010 at 12:24 PM, gregory dudek  wrote:
> The Telnet module telnetlib.py can be
> very slow -- unusably slow -- for large automated data transfers.  There are 
> typically done in raw mode.
>
> The attached patch greatly increased the speed of telnet interactions in raw 
> mode.  I submitted this a couple of year ago, but it was for an older branch 
> of python.
>
> There are 2 key things being done:
>  1) concatenations string with string.join instead of '+'  (which is probably 
> a minor issue)
>  2) wholesale appending the raw and processed buffers when the IAC character 
> is not found.  The should be examined
>     carefully since I am not an expert in the Telnet protocol, but it seems 
> to work very well giving me a 5x speedup.

As others mentioned, please post the bug to the tracker.  Also, please
assign the patch to me ("jackdied") and mention the previous bug
number - I thought I had reviewed all the telnetlib bugs including
those that were closed WONTFIX.

Thanks for the kick in the pants, I have a whole new inner loop for
data processing but I haven't applied it.  I've been adding unit tests
to the module so I could be sure I wouldn't break anything but never
finished the job.

-Jack
___
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] Peculiar import code in pickle.py

[Jack Diederich]

On Tue, Jul 13, 2010 at 1:57 PM, Benjamin Peterson  wrote:
> 2010/7/13 Alexander Belopolsky :
>> On Tue, Jul 13, 2010 at 11:34 AM, Antoine Pitrou  wrote:
>>> On Tue, 13 Jul 2010 11:25:23 -0400
>> ..
>>> Only for top-level modules:
>>>
>>>>>> __import__("distutils.core", level=0)
>>> >> '/home/antoine/py3k/__svn__/Lib/distutils/__init__.py'>
>>>>>> sys.modules["distutils.core"]
>>> >> '/home/antoine/py3k/__svn__/Lib/distutils/core.py'>
>>
>> That's right, but I believe the recommended way to achieve that
>> behavior is to supply a dummy fromlist:
>>
>>>>> __import__("distutils.core", fromlist=["dummy"], level=0)
>> > '/Users/sasha/Work/python-svn/py3k/Lib/distutils/core.py'>
>
> No! That's not recommended and a complete hack. The "dance" or
> importlib.import_module is preferred.

A complete hack with a long pedigree:
  module = __import__(modname, None, None, 'python2.4 is silly,
revisit this line in 2.5')

I think that line in a code base of mine didn't get altered until 2.6.something.

Hack-ily,

-Jack
___
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] Thoughts fresh after EuroPython

[Jack Diederich]

On Sun, Jul 25, 2010 at 2:26 PM, Jesse Noller  wrote:
> On Sat, Jul 24, 2010 at 10:08 AM, Guido van Rossum  wrote:
>> - After seeing Raymond's talk about monocle (search for it on PyPI) I
>> am getting excited again about PEP 380 (yield from, return values from
>> generators). Having read the PEP on the plane back home I didn't see
>> anything wrong with it, so it could just be accepted in its current
>> form. Implementation will still have to wait for Python 3.3 because of
>> the moratorium. (Although I wouldn't mind making an exception to get
>> it into 3.2.)
>
> I, like others, want PEP 380 to be in and done (it's exciting!).
> However, we knew going into the moratorium that it would negatively
> affect PEP 380 - as a co-author, it was one of the few things which
> made me second-guess the implementation of the moratorium. So; in this
> case I'd have to vote no, we knew going in it would do this.

I was/am pro PEP 380 and pro Moratorium.  We knew going in to the
moratorium that PEP 380 wouldn't be included and talked about it
extensively.  We should honor that now for the same reasons we talked
about then: declaring "no syntax changes" allows for a focus on the
stdlib.

-Jack
___
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] Goodbye

[Jack Diederich]

On Tue, Sep 21, 2010 at 7:58 PM, Mark Lawrence  wrote:
> I'm rather sad to have been sacked, but such is life.  I won't be doing any
> more work on the bug tracker for obvious reasons, but hope that you who have
> managed to keep your voluntary jobs manage to keep Python going.

Umm, what?  You mean http://bugs.python.org/issue2180  ?

""" Mark, please stop closing these based on age.
The needs to be a determination whether this
is a valid bug.  If so, then a patch is needed.
If not, it can be closed."""

Am I missing something?

-Jack
___
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] Tracker BD Was:Goodbye

[Jack Diederich]

On Wed, Sep 22, 2010 at 11:46 PM, Raymond Hettinger
 wrote:
>
> On Sep 22, 2010, at 6:24 PM, R. David Murray wrote:
>
>> On Wed, 22 Sep 2010 19:18:35 -0400, Terry Reedy  wrote:
>>
>>> deputed tracker authority/ies. Not everyone has the same idea about how
>>> to handle the various fields and processes. Who decides in cases of
>>> disagreement?
>>
>> We discussed this a while back and I don't think we really have a tracker
>> BD.  Brett and Martin come closest, but mostly we just sort of evolve
>> a rough consensus.
>
> IMO, Benjamin and Antoine are the closest.  They devote a substantial
> portion of their lives to Python and have been our most active
> contributors in the last year.   They read almost every tracker post,
> read every check-in, and continuously monitor the IRC channel.

Off topic-er.  Does anyone have scripts that pull data on how many
committers commit or how many trac admins admin?  I'm not asking for
punitive reasons - I'd be the first against the wall - but I wouldn't
mind graphing it.  Power law, methinks.  With big, confounding, and
jumbley spikes in the Spring for PyCon.

Likewise for mailing list subscriptions.  Personally I've gone back
and forth between subscribing to everything (-list -dev -commits -bugs
-ideas, et al) and subscribing to almost nothing.

-Jack
___
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] API for binary operations on Sets

[Jack Diederich]

I will say something snarky now and (hopefully) something useful tomorrow.

When ABCs went in I was +0 because, like annotations, I was told I
wouldn't have to care about them.  That said; I do actually care about
the set interface and what "set-y-ness" means for regular duck typing
reasons.  What people expect sets to do is what sets-alikes should do.

-Jack
___
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] closing files and sockets in a timely manner in the stdlib

[Jack Diederich]

On Fri, Oct 29, 2010 at 8:35 PM, Brett Cannon  wrote:
> For those of you who have not noticed, Antoine committed a patch that
> raises a ResourceWarning under a pydebug build if a file or socket is
> closed through garbage collection instead of being explicitly closed.

Just yesterday I discovered /proc//fd/ which is a list
of open file descriptors for your PID on *nix and includes all open
files, pipes, and sockets.  Very handy, I filed some tickets about
company internal libs that were opening file handles as a side effect
of import (logging mostly).  I tried to provoke standard python
imports (non-test) to leave some open handles and came up empty.

-Jack
___
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] closing files and sockets in a timely manner in the stdlib

[Jack Diederich]

On Sat, Oct 30, 2010 at 3:06 PM, Glyph Lefkowitz
 wrote:
>
> On Oct 30, 2010, at 2:39 PM, Jack Diederich wrote:
>
> On Fri, Oct 29, 2010 at 8:35 PM, Brett Cannon  wrote:
>
> For those of you who have not noticed, Antoine committed a patch that
>
> raises a ResourceWarning under a pydebug build if a file or socket is
>
> closed through garbage collection instead of being explicitly closed.
>
> Just yesterday I discovered /proc//fd/ which is a list
> of open file descriptors for your PID on *nix and includes all open
> files, pipes, and sockets.  Very handy, I filed some tickets about
> company internal libs that were opening file handles as a side effect
> of import (logging mostly).  I tried to provoke standard python
> imports (non-test) to leave some open handles and came up empty.
>
> That path (and anything below /proc, really) is a list of open file
> descriptors specifically on Linux, not "*nix".  Also on linux, you can avoid
> "" by just doing "/proc/self".

I was happy to find out that the /proc system came from Plan9 because
I always thought Plan9 was dead water.  But in this particular case
Plan9 outdid System7 in the the realm of "everything is a file" by
making everything a file.
___
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-checkins] TRUNK IS UNFROZEN, available for 2.6 work if you are so inclined

[Jack Diederich]

On Thu, Aug 17, 2006 at 09:07:53PM +0200, Georg Brandl wrote:
> Jack Diederich wrote:
> 
> > Looks good to me.  While you are on that page do you want to change
> > 
> > l = PyList_New(3);
> > x = PyInt_FromLong(1L);
> > PySequence_SetItem(l, 0, x); Py_DECREF(x);
> > x = PyInt_FromLong(2L);
> > PySequence_SetItem(l, 1, x); Py_DECREF(x);
> > x = PyString_FromString("three");
> > PySequence_SetItem(l, 2, x); Py_DECREF(x);
> > 
> > to
> > 
> > l = PyList_New(3);
> > x = PyInt_FromLong(1L);
> > PyList_SetItem(l, 0, x);
> > x = PyInt_FromLong(2L);
> > PyList_SetItem(l, 1, x);
> > x = PyString_FromString("three");
> > PyList_SetItem(l, 2, x);
> > 
> > The example code causes segfaults and probably always has (at last to 2.2)
> 
> Interesting! From a naive POV, the docs' example is quite right.
> 
> The segfault occurs because list_ass_item Py_DECREFs the old item (which
> segfaults because the old items are NULL in a newly created list).
> PyList_SetItem does a Py_XDECREF.
> 
> The docs to PyList_New, however, do not explicitly say that the new list
> must only be filled using PyList_SetItem.
> 
> So please, someone, decide what's broken here!

The docs, this is from a thread yesterday and today on c.l.py

http://groups.google.com/group/comp.lang.python/browse_frm/thread/158c8797ee2dccab/

-Jack
___
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] os.spawnlp() missing on Windows in 2.4?

[Jack Diederich]

On Sat, Aug 19, 2006 at 04:34:16AM +0100, Steve Holden wrote:
> Scott Dial wrote:
> > Guido van Rossum wrote:
> > 
> >>I just got a report from a Windows user that os.spawnlp() is missing
> >>from Python 2.4, despite being mentioned in the docs. Can someone
> >>confirm this? My Windows box is resting. :-)
> >>
> > 
> > 
> > "Availability: Unix, Windows. spawnlp(), spawnlpe(), spawnvp() and 
> > spawnvpe() are not available on Windows. New in version 1.6."
> > 
> > One could argue that it presented poorly, but it reads completely 
> > correct. Alternatively one could says "The 'p' variants are unavailable 
> > on Windows." but that would be assuming someone understand there was a 
> > scheme to the names :-)
> > 
> How about:
> 
> "Availability: Unix; Windows PARTIAL (spawnlp(), spawnlpe(), spawnvp() 
> and spawnvpe() are not implemented). New in version 1.6"
> 
Or

*Availability: Unix: All, Windows: spawnl(), spawnle(), spawnv(), 
spawnve() only.  New in version 1.6

Might as well positively list the half that is there instead of the half
that isn't.

-Jack
___
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] ctypes and win64

[Jack Diederich]

On Sat, Aug 19, 2006 at 05:19:40AM -0400, Tim Peters wrote:
> [Steve Holden]
> >> Reasonable enough, but I suspect that Thomas' suggestion might save us
> >> from raising false hopes. I'd suggest that the final release
> >> announcement point out that this is the first release containing
> >> specific support for 64-bit architectures (if indeed it is)
> 
> [Martin v. L?wis]
> > It isn't. Python ran on 64-bit Alpha for nearly a decade now (I guess),
> > and was released for Win64 throughout Python 2.4. ActiveState has
> > been releasing an AMD64 package for some time now.
> 
> Python has also been used on 64-bit Crays, and I actually did the
> first 64-bit port in 1993 (to a KSR Unix machine -- took less than a
> day to get it running fine!  Guido's an excellent C coder.).  Win64 is
> the first (and probably only forever more) where sizeof(long) <
> sizeof(void*), and that caused some Win64-unique pain, and may cause
> more.
> 
> BTW, at least two of the people at the NFS sprint earlier this year
> were compiling and running Python on Win64 laptops.  It's "solid
> enough", and surely nobody expects that Win64 users expect 100%
> perfection of anything they run <0.5 wink>.

It has always "just worked" for me on Opterons + Debian.
Python 2.4 (#1, May 31 2005, 10:19:45) 
[GCC 3.3.5 (Debian 1:3.3.5-12)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import sys
>>> sys.maxint
9223372036854775807

Thanks to the Alphas for making AMD64 on *nix a no-brainer,

-Jack
___
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] gcc 4.2 exposes signed integer overflows

[Jack Howarth]

   I discovered that gcc 4.2 exposes a flaw with
signed integer overflows in python. This bug and the
necessary fix has been discussed in detail on the gcc
mailing list. I have filed a detailed bug report and
the recommended patch proposed by the gcc developers.
This problem should be addressed BEFORE python 2.5 is
released. The bug report is...

[ 1545668 ] gcc trunk (4.2) exposes a signed integer overflows

in the python sourceforge bug tracker. Thanks in advance
for attempting to fix this before Python 2.5 is released.
 Jack
___
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] gcc 4.2 exposes signed integer overflows

[Jack Howarth]

Guido,
You'll never win that argument with the gcc developers. If you
rely on undefined behavior in the c language standard, they have
in the past, and will continue to, feel free to ignore those cases.
If you plan on ignoring this issue, just be prepared to see a 
testcase failure in the python testsuite when python is built with
gcc 4.2.
    Jack
___
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] gcc 4.2 exposes signed integer overflows

[Jack Howarth]

I believe some of the others here might be interested in
some other postings on the gcc mailing list regarding this issue
(which weren't cross-posted here)...

http://gcc.gnu.org/ml/gcc/2006-08/msg00516.html
http://gcc.gnu.org/ml/gcc/2006-08/msg00517.html

It makes clear that the impact of this change in gcc was considered
and the reasoning on their decision to follow the standard so closely.

http://gcc.gnu.org/ml/gcc/2005-06/msg01238.html

Just so other beside Guido see those.
  Jack
___
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, lipo and the future?

[Jack Howarth]

I am curious if there are any plans to support
the functionality provided by lipo on MacOS X to
create a python release that could operate at either
32-bit or 64-bit on Darwin ppc and Darwin intel? My
understanding was that the linux developers are very
interested in lipo as well as an approach to avoid
the difficulty of maintaining separate lib directories
for 32 and 64-bit libraries. Thanks in advance for
any insights on this issue.
  Jack
___
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, lipo and the future?

[Jack Jansen]

Just wondering: is it a good idea in the first place to create a  
universal 32/64 bit Python on MacOSX?

On MacOS you don't pay a penalty or anything for running in 32-bit  
mode on any current hardware, so the choice of whether to use 32 or  
64 bits really depends on the application. A single Python  
interpreter that can run in both 32 and 64 bit mode would possibly  
make this more difficult rather than easier. I think I'd prefer a  
situation where we have python32 and python64 (with both being ppc/ 
intel fat) and python being a symlink to either, at the end-users'  
discretion.

For extension modules it's different, though: there it would be nice  
to be able to have a single module that could load into any Python  
(32/64 bit, Intel/PPC) on any applicable MacOSX version.
--
Jack Jansen, <[EMAIL PROTECTED]>, http://www.cwi.nl/~jack
If I can't dance I don't want to be part of your revolution -- Emma  
Goldman


___
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, lipo and the future?

[Jack Howarth]

Martin,
I believe if you use the Xcode project management the
Universal binary creation is automated. Currently they
support the i386/ppc binaries but once Leopard comes
out you will see i386/x86_64/ppc/ppc64 binaries for
shared libraries.
 Jack
___
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] test_itertools fails for trunk on x86 OS X machine

[Jack Diederich]

The python binary is out of step with the test_itertools.py version.
You can generate this same error on your own box by reverting the
change to itertoolsmodule.c but leaving the new test in test_itertools.py

I don't know why this only happened on that OSX buildslave

On Thu, Sep 21, 2006 at 02:34:40PM -0700, Grig Gheorghiu wrote:
> One of the Pybots buildslaves has been failing the 'test' step, with
> the culprit being test_itertools:
> 
> test_itertools
> test test_itertools failed -- Traceback (most recent call last):
>   File
> "/Users/builder/pybots/pybot/trunk.osaf-x86/build/Lib/test/test_itertools.py",
> line 62, in test_count
> self.assertEqual(repr(c), 'count(-9)')
> AssertionError: 'count(4294967287)' != 'count(-9)'
> 
> This started to happen after
> .
> 
> The complete log for the test step on that buildslave is here:
> 
> http://www.python.org/dev/buildbot/community/all/x86%20OSX%20trunk/builds/19/step-test/0
> 
> Grig
> 
> 
> -- 
> http://agiletesting.blogspot.com
> ___
> 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/jackdied%40jackdied.com
> 
___
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] test_itertools fails for trunk on x86 OS X machine

[Jack Diederich]

On Thu, Sep 21, 2006 at 03:28:04PM -0700, Grig Gheorghiu wrote:
> On 9/21/06, Jack Diederich <[EMAIL PROTECTED]> wrote:
> > The python binary is out of step with the test_itertools.py version.
> > You can generate this same error on your own box by reverting the
> > change to itertoolsmodule.c but leaving the new test in test_itertools.py
> >
> > I don't know why this only happened on that OSX buildslave
> 
> Not sure what you mean by out of step. The binary was built out of the
> very latest itertoolsmodule.c, and test_itertools.py was also updated
> from svn. So they're both in sync IMO. That tests passes successfully
> on all the other buildslaves in the Pybots farm (x86 Ubuntu, Debian,
> Gentoo, RH9, AMD-64 Ubuntu)
> 

When I saw the failure, first I cursed (a lot).  Then I followed the repr
all the way down into stringobject.c, no dice.  Then I noticed that the
failure is exactly what you get if the test was updated but the old
module wasn't.

Faced with the choice of believing in a really strange platform specific 
bug in a commonly used routine that resulted in exactly the failure caused 
by one of the two files being updated or believing a failure occurred in the
long chain of networks, disks, file systems, build tools, and operating 
systems that would result in only one of the files being updated -
I went with the latter.

I'll continue in my belief until my dying day or until someone with OSX
confirms it is a bug, whichever comes first.

not-gonna-sweat-it-ly,

-Jack
___
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] test_itertools fails for trunk on x86 OS X machine

[Jack Diederich]

On Fri, Sep 22, 2006 at 06:09:41AM +0200, "Martin v. L?wis" wrote:
> Jack Diederich schrieb:
> > Faced with the choice of believing in a really strange platform specific 
> > bug in a commonly used routine that resulted in exactly the failure caused 
> > by one of the two files being updated or believing a failure occurred in the
> > long chain of networks, disks, file systems, build tools, and operating 
> > systems that would result in only one of the files being updated -
> > I went with the latter.
> 
> Please reconsider how subversion works. It has the notion of atomic
> commits, so you either get the entire change, or none at all.
> 
> Fortunately, the buildbot keeps logs of everything it does:
> 
> http://www.python.org/dev/buildbot/trunk/g4%20osx.4%20trunk/builds/1449/step-svn/0
> 
> shows
> 
> ULib/test/test_itertools.py
> UModules/itertoolsmodule.c
> Updated to revision 51950.
> 
> So it said it updated both files. But perhaps it didn't build them?
> Let's check:
> 
> 
> http://www.python.org/dev/buildbot/trunk/g4%20osx.4%20trunk/builds/1449/step-compile/0
> 
> has this:
> 
> building 'itertools' extension
> 
> gcc -fno-strict-aliasing -Wno-long-double -no-cpp-precomp
> -mno-fused-madd -g -Wall -Wstrict-prototypes -I.
> -I/Users/buildslave/bb/trunk.psf-g4/build/./Include
> -I/Users/buildslave/bb/trunk.psf-g4/build/./Mac/Include -I./Include -I.
> -I/usr/local/include -I/Users/buildslave/bb/trunk.psf-g4/build/Include
> -I/Users/buildslave/bb/trunk.psf-g4/build -c
> /Users/buildslave/bb/trunk.psf-g4/build/Modules/itertoolsmodule.c -o
> build/temp.macosx-10.3-ppc-2.6/Users/buildslave/bb/trunk.psf-g4/build/Modules/itertoolsmodule.o
> 
> gcc -bundle -undefined dynamic_lookup
> build/temp.macosx-10.3-ppc-2.6/Users/buildslave/bb/trunk.psf-g4/build/Modules/itertoolsmodule.o
> -L/usr/local/lib -o build/lib.macosx-10.3-ppc-2.6/itertools.so
> 
> So itertools.so is regenerated, as it should; qed.
> 

I should leave the tounge-in-cheek bombast to Tim and Frederik, especially
when dealing with what might be an OS & machine specific bug.  The next
checkin and re-test will or won't highlight a failure and certainly someone 
with a g4 will try it out before 2.5.1 goes out so we'll know if it was a 
fluke soonish. The original error was mine, I typed "Size_t" instead of 
"Ssize_t" and while my one-char patch might also be wrong (I hope not, I'm 
red-faced enough as is) we should find out soon enough.

-Jack
___
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] test_itertools fails for trunk on x86 OS X machine

[Jack Diederich]

On Thu, Sep 21, 2006 at 10:23:54PM -0700, Neal Norwitz wrote:
> On 9/21/06, Jack Diederich <[EMAIL PROTECTED]> wrote:
> >
> > I should leave the tounge-in-cheek bombast to Tim and Frederik, especially
> > when dealing with what might be an OS & machine specific bug.  The next
> > checkin and re-test will or won't highlight a failure and certainly someone
> > with a g4 will try it out before 2.5.1 goes out so we'll know if it was a
> > fluke soonish. The original error was mine, I typed "Size_t" instead of
> > "Ssize_t" and while my one-char patch might also be wrong (I hope not, I'm
> > red-faced enough as is) we should find out soon enough.
> 
> It looks like %zd of a negative number is treated as an unsigned
> number on OS X, even though the man page says it should be signed.
> 
> """
> The z modifier, when applied to a d or i conversion, indicates that
> the argument is of a signed type equivalent in size to a size_t.
> """
> 
> The program below returns -123 on Linux and 4294967173 on OS X.
> 
> n
> --
> #include 
> int main()
> {
> char buffer[256];
>   if(sprintf(buffer, "%zd", (size_t)-123) < 0)
> return 1;
>  printf("%s\n", buffer);
>  return 0;
> }

Consider me blushing even harder for denying the power of the buildbot
(and against all evidence).  Yikes, didn't any other tests trigger this?

sprat:~/src/python-head# find ./ -name '*.c' | xargs grep '%zd' | wc -l
65

-Jack
___
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 Doc problems

[Jack Jansen]

On 29-sep-2006, at 4:24, Greg Ewing wrote:

An example of a good way to do it is the original Inside
Macintosh series. Each chapter started with a narrative-style
"About this module" kind of section, that introduced the
relevant concepts and explained how they fitted together,
without going into low-level details. Then there was a
"Reference" section that systematically went through and
gave all the details of the API.


Yep, this is exactly what I often miss in the Python library docs.
The module intro sections often do contain the "executive
summary" of the module, so that you can quickly see whether this
module could indeed help you solve the problem at hand.
But then you go straight to descriptions of classes and methods,
and there is often no info on how things are plumbed together, both
within the module (how the classes relate to each other) and
more globally (how this module relates to others, see also).

A similar thing occurs one level higher in the library hierarchy:
the section introductions are little more that a list of all the
modules in the section.
--
Jack Jansen, <[EMAIL PROTECTED]>, http://www.cwi.nl/~jack
If I can't dance I don't want to be part of your revolution -- Emma  
Goldman





smime.p7s
Description: S/MIME cryptographic 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/archive%40mail-archive.com

[Python-Dev] OT: How many other people got this spam?

[Jack Jansen]

I was wondering: how many other people who maintain websites (well:  
"maintain" might be a bit of a misnomer in my case:-) related to  
Python have also got this spam?

Begin forwarded message:

> From: "Snake Tracks" <[EMAIL PROTECTED]>
> Date: October 1, 2006 21:21:45 GMT+02:00
> To: Cwi <[EMAIL PROTECTED]>
> Subject: Special Invitation for cwi.nl from Snake Tracks
>
> Fellow Website Owner/Operator;
>
> As of September 29th, 2006 we will be launching what is soon to be the
> worlds largest snake enthusiast website.  The website contains  
> valuable
> information for all those interested in snakes including care sheets,
> species information and identification, breeding information, and an
> extensive list of snake specific forums.
>
> We welcome you to visit our website and join our community of snake
> enthusiasts worldwide. Currently we are browsing through Google and
> other major search engines looking for websites we feel would make  
> good
> link partners.  I have personally come across your site and think that
> exchanging links could benefit both of our businesses. By linking  
> to us
> you will receive a reciprocal link and be showcased in front of all  
> our
> visitors.
>
> If you are interested in this partnership please add one of the
> following text links or banners to a high traffic area on your  
> website:
>
> 1) Snake Tracks - The Worlds Largest Snake Enthusiast Website. Visit
> our site for care sheets, species information, field herping
> information, breeding, captive care, and our extensive list of snake
> enthusiast forums.
>
> 2) Snake Tracks Forums - Visit the Worlds Largest Collection of Snake
> Enthusiast forums including our field herping, captive care, habitat
> design, and regional forums.
>
> 3) Snake Care Sheets - Visit the Worlds Largest Snake Enthusiast
> Website. Forums, Care Sheets, Field Herping, Species information and
> more.
>
> You may also visit our link page to choose from several banner images
> and text links.  Once you have linked to our website, fill out the  
> form
> and we will add your site to our directory.
>
> http://www.snaketracks.com/linktous.html
>
> I look forward to hearing from you in regards to this email.  Please
> allow up to 24 hours for a response as we are currently receiving
> extremely large amounts of email.
>
> Sincerely;
> Blair Russell - Snaketracks.com
>

--
Jack Jansen, <[EMAIL PROTECTED]>, http://www.cwi.nl/~jack
If I can't dance I don't want to be part of your revolution -- Emma  
Goldman


___
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] Segfault in python 2.5

[Jack Jansen]

On 18-Oct-2006, at 22:08 , Michael Hudson wrote:
>> Unfortunately, I've been attempting for hours to
>> reduce the problem to a completely self-contained script, but it is
>> resisting my efforts due to timing problems.

Has anyone ever tried to use helgrind (the valgrind module, not the  
heavy metal band:-) on Python?
--
Jack Jansen, <[EMAIL PROTECTED]>, http://www.cwi.nl/~jack
If I can't dance I don't want to be part of your revolution -- Emma  
Goldman


___
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] The "lazy strings" patch

[Jack Jansen]

On  23-Oct-2006, at 16:58 , Larry Hastings wrote:I genuinely don't know how many external Python extension modules are well-behaved in this regard.  But in case it helps: I just checked PIL, NumPy, PyWin32, and SWIG, and all of them were well-behaved.  Apart from stringobject.c, there was exactly one spot in the Python source tree which made assumptions about the structure of PyStringObjects (Mac/Modules/macos.c).  It's in the block starting with the comment "This is a hack:".  Note that this is unfixed in my patch, so just now all code using that self-avowed "hack" will break.As the author of that hack, that gives me an idea for where you should look for code that will break: code that tries to expose low-level C interfaces to Python. (That hack replaced an even earlier worse hack, that took the id() of a string in Python and added a fixed number to it to get at the address of the string, to fill it into a structure, blush).Look at packages such as win32, PyObjC, ctypes, bridges between Python and other languages, etc. That's where implementors are tempted to bend the rules of Official APIs for the benefit of serious optimizations. --Jack Jansen, <[EMAIL PROTECTED]>, http://www.cwi.nl/~jackIf I can't dance I don't want to be part of your revolution -- Emma Goldman ___
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: Adding data-type objects to Python

[Jack Jansen]

Would it be possible to make the data-type objects subclassable, with the subclasses being able to override the equality test?The range of data types that you've specified in the PEP are good enough for most general use, and probably for NumPy as well, but someone already came up with the example of image formats, which have their whole own range of data formats. I could throw in audio formats (bits per sample, excess-N or signed or ulaw samples, mono/stereo/5.1/etc, order of the channels), and there's probably a whole slew of other areas that have their own sets of formats.If the datatype objects are subclassable, modules could initially start by adding their own formats. So, the "jackaudio" and "jillaudio" modules would have distinct sets of formats. But then later on it should be fairly easy for them to recognize each others formats. So, jackaudio would recognize the jillaudio format "msdos linear pcm" as being identical to its own "16-bit excess-32768".Hopefully eventually all audio module writers would get together and define a set of standard audio formats. -- Jack Jansen, <[EMAIL PROTECTED]>, http://www.cwi.nl/~jack If I can't dance I don't want to be part of your revolution -- Emma Goldman  

smime.p7s
Description: S/MIME cryptographic 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/archive%40mail-archive.com

Re: [Python-Dev] Python and the Linux Standard Base (LSB)

[Jack Jansen]

On 28-nov-2006, at 22:05, Guido van Rossum wrote:

> On 11/28/06, Barry Warsaw <[EMAIL PROTECTED]> wrote:
>> There's a related issue that may or may not be in scope for this
>> thread.  For distros like Gentoo or Ubuntu that rely heavily on their
>> own system Python for the OS to work properly, I'm quite loathe to
>> install Cheeseshop packages into the system site-packages.
>
> I wonder if would help if we were to add a vendor-packages directory
> where distros can put their own selection of 3rd party stuff they
> depend on, to be searched before site-packages, and a command-line
> switch that ignores site-package but still searches vendor-package.
> (-S would almost do it but probably suppresses too  much.)

+1.

We've been running into this problem on the Mac since Apple started  
shipping Python.

There's another standard place that is searched on MacOS: a per-user  
package directory ~/Library/Python/2.5/site-packages (the name "site- 
packages" is a misnomer, really). Standardising something here is  
less important than for vendor-packages (as the effect can easily be  
gotten by adding things to PYTHONPATH) but it has one advantage:  
distutils and such could be taught about it and provide an option to  
install either systemwide or for the current user only.
--
Jack Jansen, <[EMAIL PROTECTED]>, http://www.cwi.nl/~jack
If I can't dance I don't want to be part of your revolution -- Emma  
Goldman


___
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] Renaming Include/object.h

[Jack Jansen]

On 3-Jan-2007, at 23:17 , Gregory P. Smith wrote:
> +1   on using the python/*.h subdirectory.

I'm a bit concerned about the "python/*.h": could it cause trouble in  
combination with Apple's framework naming convention (#include  
 magically gets the header out of the  
quicktime framework) and the case-insensitiveness of the Mac filesystem?

Will
#include "python/blabla.h"
always find that file along the -I paths, and not somehow  
accidentally start looking for /Library/Framework/Python.framework/ 
Headers/blabla.h?
--
Jack Jansen, <[EMAIL PROTECTED]>, http://www.cwi.nl/~jack
If I can't dance I don't want to be part of your revolution -- Emma  
Goldman


___
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-3000] Warning for 2.6 and greater

[Jack Diederich]

On Wed, Jan 10, 2007 at 06:04:05PM -0800, Raymond Hettinger wrote:
> [Anthony Baxter]
> > I've had a number of people say that this is something they would 
> > really, really like to see - the idea is both to let people migrate 
> > more easily, and provide reassurance that it won't be that bad to 
> > migrate!
> 
> If Py3.0 is going to come out before Py2.6, can we table the discussion
> until then?  We may find that a) migration was easier than we thought,
> b) that stand-alone migration tools are sufficient, or c) by the time
> Py2.6 comes-out, no one cares about having 2.x vs 3.x warnings.
> OTOH, if people do care, then we'll have a strong case for loading
> these warnings into Py2.6 before it gets close to being final.

I'm also a fan of not scratching something until it itches but if
someone else already feels the itch and wants to do the work +0.
The pro warnings camp has said it won't add interpreter overhead unless
you ask for it (and they are willing to test that it is so).

> Also, I'm wondering if the desire for 2.6 warnings is based on the notion 
> that 
> it will be possible to get large tools to work under both Py2.x and Py3.x.
> With all the module renaming/packaging, old-style classes disappearing,
> encoded text objects, real division and whatnot; that notion may be
> a pipe-dream.

No one has seriously suggested that it would be easy or if you prefer
no one serious has suggested it would be easy ;)

> As far as "reassurance that it won't be that bad to migrate", screens full
> of warnings may be less than reassuring.

If folks want to put in the effort (and people heavier than me have 
offered) to support light-weight optional warnings in addition to the
2to3 tool I can't complain.  It seems redundant to me but their time isn't
mine.

-Jack
___
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] file(file)

[Jack Jansen]

On  12-Jan-2007, at 19:01 , Guido van Rossum wrote:


On 1/12/07, A.M. Kuchling <[EMAIL PROTECTED]> wrote:

Many types in Python are idempotent, so that int(1) works
as expected, float(2.34)==2.34, ''.join('hello')=='hello'
et cetera.


I'm not sure I understand the use case; I don't believe I've ever felt
the need for this.


I have oodles of routines of the form
def foo(thefile):
if type(thefile) == str: thefile = open(thefile)
or
if not hasattr(thefile, 'read'): thefile = open(thefile)
or something similar.


We should also consider the semantics in more detail. Should the seek
position be shared between the two objects? What about buffering?


That's definitely the hard part. But it's somewhat similar to  
"normal" mutable objects which are (I think always, right?) shallow  
copied when used in a constructor.

--
Jack Jansen, <[EMAIL PROTECTED]>, http://www.cwi.nl/~jack
If I can't dance I don't want to be part of your revolution -- Emma  
Goldman





smime.p7s
Description: S/MIME cryptographic 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/archive%40mail-archive.com

Re: [Python-Dev] New syntax for 'dynamic' attribute access

[Jack Jansen]

On 12-feb-2007, at 0:45, Ben North wrote:

>
>self.(method_name) = self.metadata.(method_name)

I like the functionality, but I don't like the syntax, to me it looks  
too much like a method call.

To me self.[method_name] = self.metadata.[method_name] looks better:  
what we're doing here is more like dictionary lookup than calling  
functions.
--
Jack Jansen, <[EMAIL PROTECTED]>, http://www.cwi.nl/~jack
If I can't dance I don't want to be part of your revolution -- Emma  
Goldman


___
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] PEP 306 changes (How to Change Python's Grammar)

[Jack Diederich]

As I found when writing the class decorator patch PEP 306 hasn't been
updated since the new AST was added.  Here is a suggested replacement
block for the Checklist section.  AST hackers feel free to make
suggestions.

Checklist

__ Grammar/Grammar: OK, you'd probably worked this one out :)

__ Parser/Python.asdl may need changes to match the Grammar.
   Use Parser/asdl_c.py to regenerate Include/Python-ast.h

__ Python/Python-ast.c may need changes to create the AST
   objects involved with the Grammar change.  Lib/compiler/ast.py
   will need matching changes to the pure-python AST objects.

__ Parser/pgen needs to be rerun to regenerate Include/graminit.h
   and Include/graminit.c

__ Python/compile.c: You will need to create or modify the
   compiler_* functions for your productions.

__ You may need to regenerate Lib/symbol.py and/or Lib/token.py
   and/or Lib/keyword.py

__ The parser module.  Add some of your new syntax to test_parser,
   bang on parsermodule.c until it passes.

__ The compiler package.  A good test is to compile the standard
   library and test suite with the compiler package and then check
   it runs.  You did add some of your new syntax to the test
   suite, didn't you?  There's a script in Tools/compiler that
   does this.

__ If you've gone so far as to change the token structure of
   Python, then the tokenizer library module will need to be
   changed.

__ Certain changes may require tweaks to the library module
   pyclbr.

__ Documentation must be written!
___
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] Contents of test_bool

[Jack Diederich]

On Wed, Mar 21, 2007 at 03:37:02PM -0500, Collin Winter wrote:
> Is there any reason for test_bool to contain assertions like these?
> 
> self.assertIs({}.has_key(1), False)
> self.assertIs({1:1}.has_key(1), True)
> 
> A significant portion of the file is devoted to making sure various
> things return bools (isinstance, operator.*) or handle bools correctly
> (pickle, marshal). Since these don't test the functionality of the
> bool type, is there a reason not to move these tests to more
> appropriate test files (eg, test_pickle) or removing them altogether
> (if they duplicate existing tests)?
> 
> I've started on this somewhat, but I thought I'd ask before I spent
> too much time on it.

Most of them could be moved to their specific type's test module.
There are a few (at least on the py3k branch) tests that check if
__bool__ functions really return bools and that the proper exceptions
are raised.  Those should stay in test_bool.py

-Jack
___
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] Need Survey Answers from Core Developers

[Jack Diederich]

On Fri, May 18, 2007 at 10:23:46AM -0500, Jeff Rush wrote:
> Time is short and I'm still looking for answers to some questions about
> cPython, so that it makes a good showing in the Forrester survey.
> 
[snip]
> 
> 4) How many committers to the cPython core are there?
> 
>I don't have the necessary access to the pydotorg infrastructure
>to answer this -- can someone who does help me out here?

http://www.python.org/dev/committers
If the last modified date can be trusted there are currently 77 committers.
___
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] Is Demo directory removed from python3.2 ?

[Jack Diederich]

On Mon, Feb 21, 2011 at 10:02 PM, wen heping  wrote:
> Hi,
>
>   I found 2 changes in python-3.2 compared to previous python version:
>   i) Demo directory removed
>   ii) lib/libpython3.2.so.1  changed to lib/libpython3.2mu.so.1
>
>   Would someone tell me why ?

The demo directory was largely out of date (some of it by a decade).
Most of what was in it plain didn't work or was an outdated example of
how you should do things.  The good stuff was moved into the
documentation or the standard library.

-Jack
___
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-checkins] r88691 - python/branches/py3k/Lib/test/test_telnetlib.py

[Jack Diederich]

Much thanks.

On Mon, Feb 28, 2011 at 7:41 PM, antoine.pitrou
 wrote:
> Author: antoine.pitrou
> Date: Tue Mar  1 01:41:10 2011
> New Revision: 88691
>
> Log:
> Endly, fix UnboundLocalError in telnetlib
>
>
>
> Modified:
>   python/branches/py3k/Lib/test/test_telnetlib.py
>
> Modified: python/branches/py3k/Lib/test/test_telnetlib.py
> ==
> --- python/branches/py3k/Lib/test/test_telnetlib.py     (original)
> +++ python/branches/py3k/Lib/test/test_telnetlib.py     Tue Mar  1 01:41:10 
> 2011
> @@ -17,9 +17,10 @@
>         conn, addr = serv.accept()
>     except socket.timeout:
>         pass
> +    else:
> +        conn.close()
>     finally:
>         serv.close()
> -        conn.close()
>         evt.set()
>
>  class GeneralTests(TestCase):
> ___
> Python-checkins mailing list
> python-check...@python.org
> http://mail.python.org/mailman/listinfo/python-checkins
>
___
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] Vagaries of "their" in English (was Re: Support the /usr/bin/python2 symlink upstream)

[Jack Diederich]

On Sat, Mar 5, 2011 at 1:00 AM, Nick Coghlan  wrote:
> On Sat, Mar 5, 2011 at 10:40 AM, Guido van Rossum  wrote:
>> That's how I felt 20 years ago. But since then I've come to appreciate
>> they as a much better alternative to either "he or she" or "he". Just
>> get used to it.
>
> If anyone wants to further explore this question, the Stack Exchange
> on English usage is a decent place to start:
> http://english.stackexchange.com/questions/192/is-it-correct-to-use-their-instead-of-his-or-her
>
> What it boils down to is that "their" is the least bad of all of the
> available options.

No wonder that thread went to 100+ replies.

Can we cut English some slack here?  Unlike most other languages we
don't assign nouns, like rocks and sofas, a gender.  Personally I'd be
happier if everyone switched to using "she," instead of revolting
against the old default of using "he" by using the ear jarring "he or
she," or the dissonant "their."  For an amusing take on how a well
intentioned attempt to make the written law more pleasingly "correct"
see this post[1] (the ambiguous pronouns resulted in an ambiguous
statute).

English is highly mutable so I expect this will all shake out in a
generation or two.  Or maybe not - we still don't have a common word
that means a positive answer to a negative question despite centuries
of want.

-Jack

[1] 
http://volokh.com/2011/03/04/the-strange-glitch-in-the-rhode-island-rules-of-evidence/
___
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] [RELEASE] Python 2.7.2 release candidate 1

[Jack Diederich]

On Sun, May 29, 2011 at 6:47 PM, Benjamin Peterson  wrote:
> 2.7.2 is the second in bugfix release for the Python 2.7 series. 2.7 is the 
> last
> major verison of the 2.x line and will be receiving bug fixes while new 
> feature
> development focuses on 3.x.
>
> 2.7 includes many features that were first released in Python 3.1.

It might not be clear to a casual reader that the features were
released in 2.7.0 and not 2.7.2.  We don't, but many projects do
release new features with bugfix version numbers - I'm looking at you,
Django.

-Jack
___
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] Failed to install PIL on windows, may have something to do with python implementaton

[smith jack]

I am a programmer with more than two years of python programming
experience, often the debugging process may led me to the details of
some details of python implementation, this is exciting : )

Now i face a problem, that is i want to install PIL on windows, but
failed, the error messages tells that the python installation cannot
find python information in the windows register, lol, this is true,
since i got a zipped python and extract it the a directory, not using
a msi file to install python.

So how should i do in order to install PIL for my python environment?
I find that PIL installation file is a zipped file with execution
capability  (is it of 7z format?)  Now i can open this exe file using
7z, and there are lots of .py files there, with directory somewhat as
follows:

PLATLIB
PIL\*.py
PIL.pth   (a plaintext file with content "PIL")

SCRIPTS
*.py

so can i just extrat the py files to my python installation directory?
then will PIL work correctly? (should i extract PIL\*.py to
python_24\Lib\site-packages, and extract *.py to python_24\Scripts?)

Will this work?  since this have something to do with the
implementation of Python,   i come to this maillist and ask for
help.  Hope i can receive some suggestions, Thank you :)
___
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] 2.5.2 schedule?

[Jack Howarth]

   I was wondering if there is a schedule for the
release of a python 2.5.2 update? I don't see anything
like that on the www.python.org web site. Thanks in
advance for any information.
  Jack
___
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] Not backporting PEP 3115 (metaclass __prepare__)

[Jack Diederich]

We can't backport the __prepare__ syntax without requiring metaclass
definition on the 'class' line.  Because the __metaclass__ definition
can be at the end of the class in 2.6 we can't find it until after we
execute the class and that is too late to use a custom dictionary.

I wish I had thought of that yesterday,

-Jack
___
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] [Pydotorg] Should we help pythonmac.org?

[Jack Jansen]

On  19-Aug-2008, at 19:28 , Bill Janssen wrote:


My understanding is that if there is a system Python, you shouldn't
change it.  Ever.


Huge, big, honkin' +1 from me on that.  Besides, for a system Python,
you want your distribution to manage packages, not setuptools,
otherwise you confuse -- and probably break -- your system.


I find this discussion fascinating.  I install new packages into my
system Python all the time, with "/usr/bin/python setup.py install",
and that includes setuptools.  I've got PIL, ReportLab, Twisted, Xlib,
appscript, docutils, email-4.0.1, fuse, PyLucene, medusa, mutagen,
roman, setuptools, and SSL installed in the Leopard machine I'm
writing from.  They don't wind up in
/System/Library/.../site-packages/, they wind up in
/Library/Python/2.5/site-packages/, which is sort of the right place,
from an Apple point of view.  I do this on lots of Macs -- I've got a
regular posse of them at work.  And I've never had any problems with
it.


Same here: if have yet to see adverse consequences of installing third  
party packages into system Python. And now that Apple is distributing  
fairly current versions of things like PyObjC there's even little  
reason to build my own copy of Python. I have one on disk, but I find  
that I use the system Python for almost everything.


Fink (and to a lesser extent MacPorts) I don't touch with a 10 feet  
pole: too often I've created software for distribution only to find  
that it somehow, behind my back, was linked against a dynamic library  
that I had installed locally through it.

--
Jack Jansen, <[EMAIL PROTECTED]>, http://www.cwi.nl/~jack
If I can't dance I don't want to be part of your revolution -- Emma  
Goldman



___
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] Filename as byte string in python 2.6 or 3.0?

[Jack Jansen]

I'm a bit late to join in this discussion, but if unicode filenames  
are going to be the normal mode, how about this whole normalized/ 
canonical business?


This is a headache that has shown up on the Mac a couple of times,  
because MacOS prefers filenames to be NFC, whereas Python prefers its  
Unicode to be NFD (or the other way around, I keep forgetting the  
details).


To make the problem worse, even though MacOS prefers its filenames in  
the one form, it will allow filenames in the other form (which can  
happen if you mount a foreign filesystem, for example over the net).  
The fact that "incorrect" filenames can exist mean that the simple  
solution of converting NFC<->NFD in Python's open() and friends won't  
work (or, at least, it'll make some filenames inaccessible, and  
listdir() may return filenames that don't exist).



--
Jack Jansen, <[EMAIL PROTECTED]>, http://www.cwi.nl/~jack
If I can't dance I don't want to be part of your revolution -- Emma  
Goldman



___
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-3000] New proposition for Python3 bytes filename issue

[Jack Jansen]

On  30-Sep-2008, at 23:42 , Martin v. Löwis wrote:

It's the other way 'round: On Windows, Unicode file names are the
natural choice, and byte strings have limitations. In a sense, Windows
got it right - but then, they started later. Unix missed the  
opportunity

of declaring that all file APIs are UTF-8 (except for Plan-9 and OS X,
neither being "true" Unix).



How does windows (and Python on windows) handle NFC versus NFD issues?  
Can I have two files called "ümlaut.txt", one in NFD and one NFC form?  
And are both of those representable on the Python side (i.e. can they  
both be returned from listdir() and passed to open())? CIf I compare  
these two filenames, do they compare differently?

--
Jack Jansen, <[EMAIL PROTECTED]>, http://www.cwi.nl/~jack
If I can't dance I don't want to be part of your revolution -- Emma  
Goldman



___
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-3000] New proposition for Python3 bytes filename issue

[Jack Jansen]

On  1-Oct-2008, at 00:32 , Martin v. Löwis wrote:



How does windows (and Python on windows) handle NFC versus NFD  
issues?


That's left to the application.

Can I have two files called "ümlaut.txt", one in NFD and one NFC  
form?


Yes, you can. It sounds confusing, but only in a theoretical way. You
never have combining characters on Windows (at least, I don't). The
keyboard input defaults to NFC, and users normally don't type file
names, anyways, except when creating the files - later, they just use
the mouse to indicate what file they want to act on.


And are both of those representable on the Python side (i.e. can they
both be returned from listdir() and passed to open())?


Certainly!


CIf I compare
these two filenames, do they compare differently?


Certainly!


Actually, that all sounds pretty non-confusing to me:-)

So, normal users will always have the one form, and if by chance they  
get the other form they can still use the file. Also from Python, even  
when doing listdir() and then open(), everything will work just as  
expected. That there are two files that have a similar visual  
representation is not too bad, the same happens with ellipses versus  
dot-dot-dot and many other cases.


Which means the only problem area left is unix filesystems (whether on  
Linux or mounted remotely on MacOS or whatever), where filenames are  
really byte strings with only / and nul illegal.




--
Jack Jansen, <[EMAIL PROTECTED]>, http://www.cwi.nl/~jack
If I can't dance I don't want to be part of your revolution -- Emma  
Goldman



___
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] Status of the fix for the hash collision vulnerability

[Jack Diederich]

On Thu, Jan 12, 2012 at 9:57 PM, Guido van Rossum  wrote:
> Hm... I started out as a big fan of the randomized hash, but thinking more
> about it, I actually believe that the chances of some legitimate app having
>>1000 collisions are way smaller than the chances that somebody's code will
> break due to the variable hashing.

Python's dicts are designed to avoid hash conflicts by resizing and
keeping the available slots bountiful.  1000 conflicts sounds like a
number that couldn't be hit accidentally unless you had a single dict
using a terabyte of RAM (i.e. if Titus Brown doesn't object, we're
good).   The hashes also look to exploit cache locality but that is
very unlikely to get one thousand conflicts by chance.  If you get
that many there is an attack.

> This is depending on how the counting is done (I didn't look at MAL's
> patch), and assuming that increasing the hash table size will generally
> reduce collisions if items collide but their hashes are different.

The patch counts conflicts on an individual insert and not lifetime
conflicts.  Looks sane to me.

> That said, even with collision counting I'd like a way to disable it without
> changing the code, e.g. a flag or environment variable.

Agreed.  Paranoid people can turn the behavior off and if it ever were
to become a problem in practice we could point people to a solution.

-Jack
___
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] making python's c iterators picklable (http://bugs.python.org/issue14288)

[Jack Diederich]

2012/3/13 Kristján Valur Jónsson :
> http://bugs.python.org/issue14288

> In my opinion, any objects that have simple and obvious pickle semantics
> should be picklable.  Iterators are just regular objects with some state.
> They are not file pointers or sockets or database cursors.  And again, I
> argue that if these objects were implemented in .py, they would already be
> automatically picklable (indeed, itertools.py was).  The detail that some
> iterators in standard python are implemented in C should not automatically
> restrict their usage for no particular reason.

+1, things that can be pickled should be pickleable.

-Jack
___
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] Re: [Python-checkins] python/dist/src setup.py, 1.208, 1.209

[Jack Jansen]

On 18-dec-04, at 21:48, [EMAIL PROTECTED] wrote:
Update of /cvsroot/python/python/dist/src
In directory sc8-pr-cvs1.sourceforge.net:/tmp/cvs-serv21493
Modified Files:
	setup.py
Log Message:
Switch from getting LDFLAGS and CPPFLAGS from the environment to the 
Makefile.
This is to avoid a problem that inconsistently comes up where the 
environment
variable is unset while the Makefile clearly has the values set and 
are used
during ``make``.
Brett,
I'm building MacPython binary distributions with an LDFLAGS configure 
option, as in
	$PYTHONSRC/configure -C --enable-framework LDFLAGS=-Wl,-x

This has suddenly started failing with a very mysterious error message. 
When the
make tries to build the extension modules I get
	running build
	running build_ext
	usage: setup.py [options]
	setup.py: error: no such option: -W

Could this somehow be caused by your fix?
--
Jack Jansen, <[EMAIL PROTECTED]>, http://www.cwi.nl/~jack
If I can't dance I don't want to be part of your revolution -- Emma 
Goldman

___
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] Re: [Python-checkins] python/dist/src/Mac/OSX fixapplepython23.py, 1.1, 1.2

[Jack Jansen]

On 29-dec-04, at 4:35, Bob Ippolito wrote:
This is the wrong fix.  Distutils is dumber than you think.  This 
patch just breaks C++ compilation in a different way.  The correct 
solution is a patch to distutils of some kind.

from distutils/unixccompiler.py:174
if target_lang == "c++" and self.compiler_cxx:
linker[0] = self.compiler_cxx[0]
self.spawn(linker + ld_args)
"linker" is the variable expanded LDSHARED (or whatever comes out of 
sysconfig.customize_compiler).
Bah!
Any suggestions as to what to do to get c++ compilation fixed?
Also, could you point me to a readily available extension package that 
uses c++?
--
Jack Jansen, <[EMAIL PROTECTED]>, http://www.cwi.nl/~jack
If I can't dance I don't want to be part of your revolution -- Emma 
Goldman

___
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] Re: [Python-checkins] python/dist/src/Mac/OSX fixapplepython23.py, 1.2, 1.3

[Jack Jansen]

On 2-jan-05, at 4:40, Bob Ippolito wrote:
+SCRIPT="""#!/bin/sh
+export MACOSX_DEPLOYMENT_TARGET=10.3
+exec %s "[EMAIL PROTECTED]"
This script should check to see if MACOSX_DEPLOYMENT_TARGET is already 
set.  If I have some reason to set MACOSX_DEPLOYMENT_TARGET=10.4 for 
compilation (say I'm compiling an extension that requires 10.4 
features) then I'm going to have some serious problems with this fix.
I was going to do that, but then I thought it didn't make any sense, 
because this script is *only* used in the context of Apple-provided 
Python 2.3. And setting MACOSX_DEPLOYMENT_TARGET to anything other than 
10.3 (be it lower or higher) while compiling an extension for Apple's 
2.3 is going to produce disappointing results anyway.

But, if I've missed a use case, please enlighten me.
--
Jack Jansen, <[EMAIL PROTECTED]>, http://www.cwi.nl/~jack
If I can't dance I don't want to be part of your revolution -- Emma 
Goldman

___
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] Re: [Python-checkins] python/dist/src/Mac/OSX fixapplepython23.py, 1.2, 1.3

[Jack Jansen]

On 2-jan-05, at 22:35, Bob Ippolito wrote:
On 2-jan-05, at 4:40, Bob Ippolito wrote:
+SCRIPT="""#!/bin/sh
+export MACOSX_DEPLOYMENT_TARGET=10.3
+exec %s "[EMAIL PROTECTED]"
This script should check to see if MACOSX_DEPLOYMENT_TARGET is 
already set.  If I have some reason to set 
MACOSX_DEPLOYMENT_TARGET=10.4 for compilation (say I'm compiling an 
extension that requires 10.4 features) then I'm going to have some 
serious problems with this fix.
I was going to do that, but then I thought it didn't make any sense, 
because this script is *only* used in the context of Apple-provided 
Python 2.3. And setting MACOSX_DEPLOYMENT_TARGET to anything other 
than 10.3 (be it lower or higher) while compiling an extension for 
Apple's 2.3 is going to produce disappointing results anyway.

But, if I've missed a use case, please enlighten me.
You're right, of course.  I had realized that I was commenting on the 
fixpython script after I had replied, but my concern is still 
applicable to whatever solution is used for Python 2.4.1.  Anything 
lower than 10.3 is of course an error, in either case.
2.4.1 will install this fix into Apple-installed Python 2.3 (if 
applicable, i.e. if you're installing 2.4.1 on 10.3), but for its own 
use it will have the newer distutils, which understands that it needs 
to pick up MACOSX_DEPLOYMENT_TARGET from the Makefile, so it'll never 
see these scripts.
--
Jack Jansen, <[EMAIL PROTECTED]>, http://www.cwi.nl/~jack
If I can't dance I don't want to be part of your revolution -- Emma 
Goldman

___
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] Darwin's realloc(...) implementation never shrinks allocations

[Jack Jansen]

On 3 Jan 2005, at 23:40, Bob Ippolito wrote:
Most people on Mac OS X have a lot of memory, and Mac OS X generally 
does a good job about swapping in and out without causing much of a 
problem, so I'm personally not very surprised that it could go 
unnoticed this long.
*Except* when you're low on free disk space. 10.2 and before were 
really bad with this, usually hanging the machine, 10.3 is better but 
it's still pretty bad when compared to other unixen. It probably has 
something to do with the way OSX overcommits memory and swapspace, for 
which it apparently uses a different algorithm than FreeBSD or Linux.

I wouldn't be surprised if the bittorrent problem report in this thread 
was due to being low on diskspace. And that could also be true for the 
original error report that sparked this discussion.
--
Jack Jansen, <[EMAIL PROTECTED]>, http://www.cwi.nl/~jack
If I can't dance I don't want to be part of your revolution -- Emma 
Goldman

___
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] Mac questions

[Jack Jansen]

On 4 Jan 2005, at 11:41, Bob Ippolito wrote:
And finally: Is there any other way to find the true spelling of a 
file
except than a linear search with opendir()/readdir()/closedir() ?
Yes, definitely.  I'm positive you can do this with CoreServices, but 
I'm not sure it's portable to Darwin (not Mac OS X).  I'm sure there 
is some Darwin-compatible way of doing it, but I don't know it off the 
top of my head.  I'll try to remember to look into it if nobody else 
finds it first.
I haven't used pure darwin, but I assume it has support for FSRefs, 
right? Then you could use FSPathMakeRef() to turn the filename into an 
FSRef, and then FSGetCatalogInfo() to get the true filename.
--
Jack Jansen, <[EMAIL PROTECTED]>, http://www.cwi.nl/~jack
If I can't dance I don't want to be part of your revolution -- Emma 
Goldman

___
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] Let's get rid of unbound methods

[Jack Diederich]

On Tue, Jan 04, 2005 at 10:28:03AM -0800, Guido van Rossum wrote:
> In my blog I wrote:
> 
> Let's get rid of unbound methods. When class C defines a method f, C.f
> should just return the function object, not an unbound method that
> behaves almost, but not quite, the same as that function object. The
> extra type checking on the first argument that unbound methods are
> supposed to provide is not useful in practice (I can't remember that
> it ever caught a bug in my code) and sometimes you have to work around
> it; it complicates function attribute access; and the overloading of
> unbound and bound methods on the same object type is confusing. Also,
> the type checking offered is wrong, because it checks for subclassing
> rather than for duck typing.
> 
> Does anyone think this is a bad idea? Anyone want to run with it?
> 
I like the idea, it means I can get rid of this[1]

func = getattr(cls, 'do_command', None)
setattr(cls, 'do_command', staticmethod(func.im_func)) # don't let anyone on 
c.l.py see this

.. or at least change the comment *grin*,

-Jack

[1] 
http://cvs.sourceforge.net/viewcvs.py/lyntin/lyntin40/sandbox/leantin/mudcommands.py?view=auto
___
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] Let's get rid of unbound methods

[Jack Jansen]

On 4-jan-05, at 19:28, Guido van Rossum wrote:
 The
extra type checking on the first argument that unbound methods are
supposed to provide is not useful in practice (I can't remember that
it ever caught a bug in my code)
It caught bugs for me a couple of times. If I remember correctly I was 
calling methods of something that was supposed to be a mixin class but 
I forgot to actually list the mixin as a base. But I don't think that's 
a serious enough issue alone to keep the unbound method type.

But I'm more worried about losing the other information in an unbound 
method, specifically im_class. I would guess that info is useful to 
class browsers and such, or are there other ways to get at that?
--
Jack Jansen, <[EMAIL PROTECTED]>, http://www.cwi.nl/~jack
If I can't dance I don't want to be part of your revolution -- Emma 
Goldman

___
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] 2.3.5 schedule, and something I'd like to get in

[Jack Jansen]

First question: what is the Python 2.3.5 release schedule and who is 
responsible?

Second question: I thought this info was in a PEP somewhere, but I 
could only find PEPs on major releases, should I have found this info 
somewhere?

And now the question that matters: there's some stuff I'd really like 
to get into 2.3.5, but it involves changes to configure, the Makefile 
and distutils, so because it's fairly extensive I thought I'd ask 
before just committing it.

The problem we're trying to solve is that due to the way Apple's 
framework architecture works newer versions of frameworks are preferred 
(at link time, and sometimes even at runtime) over older ones. That's 
fine for most uses of frameworks, but not when linking a Python 
extension against the Python framework: if you build an extension with 
Python 2.3 to later load it into 2.3 you don't want that framework to 
be linked against 2.4.

Now there's a way around this, from MacOSX 10.3 onwards, and that is 
not to link against the framework at all, but link with "-undefined 
dynamic_lookup". This will link the extension in a way similar to what 
other Unix systems do: any undefined externals are looked up when the 
extension is dynamically loaded. But because this feature only works 
with the dynamic loader from 10.3 or later you must have the 
environment variable MACOSX_DEPLOYMENT_TARGET set to 10.3 or higher 
when you build the extension, otherwise the linker will complain.

We've solved this issue for the trunk and we can solve it for 2.4.1: if 
MACOSX_DEPLOYMENT_TARGET isn't set and we're on 10.3 we force it to 
10.3. Moreover, when it is 10.3 or higher (possibly after being forced) 
we use the dynamic_lookup way of linking extensions. We also record the 
value of MACOSX_DEPLOYMENT_TARGET in the Makefile, and distutils picks 
it up later and sets the environment variable again.

We even have a hack to fix Apple-installed Python 2.3 in place by 
mucking with lib/config/Makefile, which we can do because 
Apple-installed Python 2.3 will obviously only be run on 10.3. And we 
check whether this hack is needed when you install a later Python 
version on 10.3.

That leaves Python 2.3.5 itself. The best fix here would be to backport 
the 2.4.1 solution: configure.in 1.456 and 1.478, 
distutils/sysconfig.py 1.59 and 1.62, Makefile.pre.in 1.144. Note that 
though the build procedure for extensions will change it doesn't affect 
binary compatibility: both types of extensions are loadable by both 
types of interpreters.

I think this is all safe, and these patches shouldn't affect any system 
other than MacOSX, but I'm a bit reluctant to fiddle with the build 
procedure for a micro-release, so that's why I'm asking.
--
Jack Jansen, <[EMAIL PROTECTED]>, http://www.cwi.nl/~jack
If I can't dance I don't want to be part of your revolution -- Emma 
Goldman

___
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] 2.3.5 schedule, and something I'd like to get in

[Jack Jansen]

First question: what is the Python 2.3.5 release schedule and who is 
responsible?

Second question: I thought this info was in a PEP somewhere, but I 
could only find PEPs on major releases, should I have found this info 
somewhere?

And now the question that matters: there's some stuff I'd really like 
to get into 2.3.5, but it involves changes to configure, the Makefile 
and distutils, so because it's fairly extensive I thought I'd ask 
before just committing it.

The problem we're trying to solve is that due to the way Apple's 
framework architecture works newer versions of frameworks are preferred 
(at link time, and sometimes even at runtime) over older ones. That's 
fine for most uses of frameworks, but not when linking a Python 
extension against the Python framework: if you build an extension with 
Python 2.3 to later load it into 2.3 you don't want that framework to 
be linked against 2.4.

Now there's a way around this, from MacOSX 10.3 onwards, and that is 
not to link against the framework at all, but link with "-undefined 
dynamic_lookup". This will link the extension in a way similar to what 
other Unix systems do: any undefined externals are looked up when the 
extension is dynamically loaded. But because this feature only works 
with the dynamic loader from 10.3 or later you must have the 
environment variable MACOSX_DEPLOYMENT_TARGET set to 10.3 or higher 
when you build the extension, otherwise the linker will complain.

We've solved this issue for the trunk and we can solve it for 2.4.1: if 
MACOSX_DEPLOYMENT_TARGET isn't set and we're on 10.3 we force it to 
10.3. Moreover, when it is 10.3 or higher (possibly after being forced) 
we use the dynamic_lookup way of linking extensions. We also record the 
value of MACOSX_DEPLOYMENT_TARGET in the Makefile, and distutils picks 
it up later and sets the environment variable again.

We even have a hack to fix Apple-installed Python 2.3 in place by 
mucking with lib/config/Makefile, which we can do because 
Apple-installed Python 2.3 will obviously only be run on 10.3. And we 
check whether this hack is needed when you install a later Python 
version on 10.3.

That leaves Python 2.3.5 itself. The best fix here would be to backport 
the 2.4.1 solution: configure.in 1.456 and 1.478, 
distutils/sysconfig.py 1.59 and 1.62, Makefile.pre.in 1.144. Note that 
though the build procedure for extensions will change it doesn't affect 
binary compatibility: both types of extensions are loadable by both 
types of interpreters.

I think this is all safe, and these patches shouldn't affect any system 
other than MacOSX, but I'm a bit reluctant to fiddle with the build 
procedure for a micro-release, so that's why I'm asking.
--
Jack Jansen, <[EMAIL PROTECTED]>, http://www.cwi.nl/~jack
If I can't dance I don't want to be part of your revolution -- Emma 
Goldman

___
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] 2.3.5 schedule, and something I'd like to get in

[Jack Jansen]

[Grmpf. I should check which account I use before pressing send. Here  
goes again]

On 5-jan-05, at 1:08, Bob Ippolito wrote:
The problem we're trying to solve is that due to the way Apple's  
framework architecture works newer versions of frameworks are  
preferred (at link time, and sometimes even at runtime) over older  
ones.
Can you elaborate on that somewhat? According to
http://developer.apple.com/documentation/MacOSX/Conceptual/ 
BPFrameworks/Concepts/VersionInformation.html

there are major and minor versions of frameworks. I would think that
every Python minor (2.x) release should produce a new major framework
version of the Python framework. Then, there would be no problem.
Why does this not work?
It doesn't for reasons I care not to explain in depth, again.
But I do care:-) Specifically because I trust the crowd here to come up  
with good ideas (even if they're not Mac users:-).

Ronald already explained most of the problem, what it boils down to is  
that  multiple versions of a framework can live in a single location.  
For most applications that's better than the old MacOS9 architecture  
(which I believe is pretty similar to the Windows dll architecture)  
because you can ship a single foo.framework that contains both version  
1.2 and 1.3. There's also a symlink "Current" that will point to 1.3.  
At build time the linker will pick the version pointed at by "Current",  
but in the file it will record the actual version number. Hence, if you  
ship this framework new development will link to the newest version,  
but older programs will still load the older one.

When I did the framework python design I overlooked the fact that an  
older Python would have no way to specify that an extension would have  
to link against its own, old, framework, because on MacOS9 this wasn't  
a problem (the two had different filenames).

As an aside, I also overlooked the fact that a Python framework  
residing in /System could be overridden by one in /Library because in  
2.3 we linked frameworks by relative pathname, because I simply didn't  
envision any Python living in /System for some time to be. The -F  
options could solve that problem, but not the 2.3 and 2.4 both in  
/Library problem.

The "new" solution is basically to go back to the Unix way of building  
an extension: link it against nothing and sort things out at runtime.  
Not my personal preference, but at least we know that loading an  
extension into one Python won't bring in a fresh copy of a different  
interpreter or anything horrible like that.
--
Jack Jansen, <[EMAIL PROTECTED]>, http://www.cwi.nl/~jack
If I can't dance I don't want to be part of your revolution -- Emma  
Goldman

___
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] 2.3.5 schedule, and something I'd like to get in

[Jack Jansen]

On 6 Jan 2005, at 00:49, Martin v. Löwis wrote:
The "new" solution is basically to go back to the Unix way of 
building  an extension: link it against nothing and sort things out 
at runtime.  Not my personal preference, but at least we know that 
loading an  extension into one Python won't bring in a fresh copy of 
a different  interpreter or anything horrible like that.
This sounds good, except that it only works on OS X 10.3, right?
What about older versions?
10.3 or later. For older OSX releases (either because you build Python 
on 10.2 or earlier, or because you've set MACOSX_DEPLOYMENT_TARGET to a 
value of 10.2 or less) we use the old behaviour of linking with 
"-framework Python".
--
Jack Jansen, <[EMAIL PROTECTED]>, http://www.cwi.nl/~jack
If I can't dance I don't want to be part of your revolution -- Emma 
Goldman

___
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] 2.3.5 schedule, and something I'd like to get in

[Jack Jansen]

On 7 Jan 2005, at 11:08, Bob Ippolito wrote:
10.3 or later. For older OSX releases (either because you build 
Python on 10.2 or earlier, or because you've set 
MACOSX_DEPLOYMENT_TARGET to a value of 10.2 or less) we use the old 
behaviour of linking with "-framework Python".
Wouldn't it be better to link with the actual dylib inside the 
framework on 10.2? Otherwise you can no longer build 2.3 extensions 
after you've installed 2.4.
It would certainly be better to do this for 10.2.
This patch implements the proposed direct framework linking:
http://python.org/sf/1097739
Looks good, I'll incorporate it. And as I haven't heard of any 
showstoppers for the -undefined dynamic_lookup (and Anthony seems to be 
offline this week) I'll put that in too.
--
Jack Jansen, <[EMAIL PROTECTED]>, http://www.cwi.nl/~jack
If I can't dance I don't want to be part of your revolution -- Emma 
Goldman

___
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] Re: [Csv] csv module and universal newlines

[Jack Jansen]

On 12-jan-05, at 2:59, Skip Montanaro wrote:
terminators = {"darwin": "\r",
   "win32": "\r\n"}
if (dialect.lineterminator != terminators.get(sys.platform, "\n") 
and
   "b" not in getattr(f, "mode", "b")):
   raise IOError, ("%s not opened in binary mode" %
   getattr(f, "name", "???"))
On MacOSX you really want universal newlines. CSV files produced by 
older software (such as AppleWorks) will have \r line terminators, but 
lots of other programs will have files with normal \n terminators.
--
Jack Jansen, <[EMAIL PROTECTED]>, http://www.cwi.nl/~jack
If I can't dance I don't want to be part of your revolution -- Emma 
Goldman

___
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] Updated Monkey Typing pre-PEP

[Jack Jansen]

On 20 Jan 2005, at 12:07, Guido van Rossum wrote:
The first problem is what I'd call incomplete duck typing.
Confit de canard-typing?
--
Jack Jansen, <[EMAIL PROTECTED]>, http://www.cwi.nl/~jack
If I can't dance I don't want to be part of your revolution -- Emma 
Goldman

___
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] Unix line endings required for PyRun* breaking embedded Python

[Jack Jansen]

On 21 Jan 2005, at 08:18, Stuart Bishop wrote:
Just van Rossum wrote:
Skip Montanaro wrote:
Just re.sub("[\r\n]+", "\n", s) and I think you're good to go.
I don't think that in general you want to fold multiple empty lines 
into
one. This would be my prefered regex:
s = re.sub(r"\r\n?", "\n", s)
Catches both DOS and old-style Mac line endings. Alternatively, you 
can
use s.splitlines():
s = "\n".join(s.splitlines()) + "\n"
This also makes sure the string ends with a \n, which may or may not 
be
a good thing, depending on your application.
Do people consider this a bug that should be fixed in Python 2.4.1 and 
Python 2.3.6 (if it ever exists), or is the resposibility for doing 
this transformation on the application that embeds Python?
It could theoretically break something: a program that uses unix 
line-endings but embeds \r or \r\n in string data.

But this is rather theoretical, I don't think I'd have a problem with 
fixing this. The real problem is: who will fix it, because the fix 
isn't going to be as trivial as the Python code posted here, I'm 
afraid...
--
Jack Jansen, <[EMAIL PROTECTED]>, http://www.cwi.nl/~jack
If I can't dance I don't want to be part of your revolution -- Emma 
Goldman

___
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] Unix line endings required for PyRun* breaking embedded Python

[Jack Jansen]

On 21-jan-05, at 14:07, Bob Ippolito wrote:
On Jan 21, 2005, at 7:44, Jack Jansen wrote:
On 21 Jan 2005, at 08:18, Stuart Bishop wrote:
Just van Rossum wrote:
Skip Montanaro wrote:
Just re.sub("[\r\n]+", "\n", s) and I think you're good to go.
I don't think that in general you want to fold multiple empty lines 
into
one. This would be my prefered regex:
s = re.sub(r"\r\n?", "\n", s)
Catches both DOS and old-style Mac line endings. Alternatively, you 
can
use s.splitlines():
s = "\n".join(s.splitlines()) + "\n"
This also makes sure the string ends with a \n, which may or may 
not be
a good thing, depending on your application.
Do people consider this a bug that should be fixed in Python 2.4.1 
and Python 2.3.6 (if it ever exists), or is the resposibility for 
doing this transformation on the application that embeds Python?
It could theoretically break something: a program that uses unix 
line-endings but embeds \r or \r\n in string data.

But this is rather theoretical, I don't think I'd have a problem with 
fixing this. The real problem is: who will fix it, because the fix 
isn't going to be as trivial as the Python code posted here, I'm 
afraid...
Well, Python already does the right thing in Py_Main, but it does not 
do the right thing from the other places you can use to run code, 
surely it can't be that hard to fix if the code is already there?
IIRC the universal newline support is in the file I/O routines, which I 
assume aren't used when you execute Python code from a string.
--
Jack Jansen, <[EMAIL PROTECTED]>, http://www.cwi.nl/~jack
If I can't dance I don't want to be part of your revolution -- Emma 
Goldman

___
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] Is msvcr71.dll re-redistributable?

[Jack Jansen]

On 3 Feb 2005, at 02:01, Phillip J. Eby wrote:
Sounds like this puts all Python users in the clear, since Python is 
the Licensee Software in that case.  So, anybody can distribute 
msvcr71 as "part of" Python.

OTOH, the other wording sounds like Python itself has to have a 
click-wrap, tear-open, or signature EULA!  IOW, the EULA appears to 
prohibit free distribution of the runtime with a program that has no 
EULA.

So, in an amusing turn of events, the EULA actually appears to forbid 
the current offering of Python for Windows, since it does not have 
such a EULA.
That was also my conclusion last year:-(
But at least Python can still be distributed without msvcr71, putting 
the burden of obtaining it on the end user, because of Python's 
license. In another project we're using GPL, and careful reading 
(disclaimer: IANAL) has not convinced me that GPL and the EULA are 
compatible. Actually, I have this vague feeling that the MSVC 7 EULA 
(plus the fact that MS isn't shipping msvcr71.dll with Windows) might 
have been drafted specifically to be incompatible with the clause in 
GPL that doesn't allow you to link against third party libraries unless 
they're part of the OS.

What we've done in that project is link with msvcr71.dll, but not 
include it in the installer. I think that we could (theoretically) 
still be dragged into court by the FSF, but at least not by Microsoft.
--
Jack Jansen, <[EMAIL PROTECTED]>, http://www.cwi.nl/~jack
If I can't dance I don't want to be part of your revolution -- Emma 
Goldman

___
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] Re: [Python-checkins] python/dist/src/Misc NEWS, 1.1237, 1.1238

[Jack Jansen]

On 4-feb-05, at 20:00, Jeremy Hylton wrote:
Add NEWS item about future parser bug.
Give back the time machine!
I already will have by the time you needed it.
I knew this was going to happen one day.
(And now we should all be getting out our copies of the HHGTTG and work 
out the horrible future past conditional tense and such. It's probably 
having shall been in book 2).
--
Jack Jansen, <[EMAIL PROTECTED]>, http://www.cwi.nl/~jack
If I can't dance I don't want to be part of your revolution -- Emma 
Goldman

___
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] Re: [Python-checkins] python/dist/src/Doc/lib libimp.tex, 1.36, 1.36.2.1 libsite.tex, 1.26, 1.26.4.1 libtempfile.tex, 1.22, 1.22.4.1 libos.tex, 1.146.2.1, 1.146.2.2

[Jack Jansen]

On 14-feb-05, at 10:23, Just van Rossum wrote:
[EMAIL PROTECTED] wrote:
 \begin{datadesc}{PY_RESOURCE}
-The module was found as a Macintosh resource.  This value can only be
-returned on a Macintosh.
+The module was found as a Mac OS 9 resource.  This value can only be
+returned on a Mac OS 9 or earlier Macintosh.
 \end{datadesc}
not entirely true: it's limited to the sa called "OS9" version of
MacPython, which happily runs natively on OSX as a Carbon app...
But as of 2.4 there's no such thing as MacPython-OS9 any more. But as 
the constant is still in there I thought it best to document it.
--
Jack Jansen, <[EMAIL PROTECTED]>, http://www.cwi.nl/~jack
If I can't dance I don't want to be part of your revolution -- Emma 
Goldman

___
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