[Python-Dev] Re: Switching to Discourse

[Simon Cross]

> I can now pull from Discourse or GH when it’s convenient for me.  It’s also 
> much easier to disengage for a few days and catch up later.

I have a question about how you handle multiple communities. I'm
subscribed to ~30 python-dev style mailing lists across different
projects. There is no way I can open up 30 Discourse sites each day.
Mail brings everything into one place for me, and I have things setup
so that new mail from python-dev style lists is separated from my
general inbox.

Are you not subscribed to a bunch of communities? Or is there some way
you aggregate or visit each forum that works nicely?

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

[Python-Dev] Re: Switching to Discourse

[Simon Cross]

I'm -1 on moving to the walled garden, but I don't expect this to change
anyone's mind. I don't know if I'll move over to Discourse or not.
___
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/FE67QZEXBGVCJ5HMNLFVDJKETIE7N2UP/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Defining tiered platform support

[Simon Cross]

+10 on making the tier platform support explicit.

I would vote not to require involving the SC in the tier changes
unless there is a strong reason to do so (e.g. there is controversy,
or e.g. Tier 1 implies a commitment of PSF infrastructure). The SC has
a lot of decisions to make as it is & hopefully Tier 2 and 3 are
really about checking a checklist (are there enough core devs
committed, are the buildbots in place, etc) that is already defined in
the PEP.

Replies to some other replies in the thread:

I like Christian's idea of explicitly supporting platforms such as
manylinux2014, Debian stable, Ubuntu stable where C extensions are
commonly built. It would help make those de facto standards more
official. Or some of the platforms supported by cibuildwheel (to
include non-Linux platforms).

I would prefer having the list in a PEP rather than the devguide. The
devguide is important, but it doesn't feel like a canonical reference
place for this sort of information.

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

[Python-Dev] Re: Python no longer leaks memory at exit

[Simon Cross]

> tl; dr Python no longer leaks memory at exit on the "python -c pass" command 
> ;-)

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

[Python-Dev] Re: Tool to search in the source code of PyPI top 5000 projects

[Simon Cross]

It's really great to see data being gathered on the impact of changes.

As we've already seen in this thread, there are many suggestions for how to
gather more data and thoughts on how the methodology might be enhanced --
and these suggestions are great -- but just having a means to gather some
important data is an excellent step.

Anecdotes and people's mental models of the Python ecosystem are certainly
valuable, but by themselves they don't provide a way to improve our joint
view of the consequences of particular changes.

As with unit tests and static analysis we should not expect such data
gathering to provide complete proof that a change is okay to make, but
having *some* quantitative data and the idea that we should pay attention
to this data are definitely a big step forward.

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

[Python-Dev] Re: Python multithreading without the GIL

[Simon Cross]

> Still, I hope you at least enjoyed my enthusiasm!

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

[Python-Dev] Re: Packing a long list of numbers into memory

[Simon Cross]

On Sun, Oct 10, 2021 at 4:23 PM Facundo Batista 
wrote:
>
> struct.pack_into(format, buffer, offset, v1, v2, ...)

I've encountered this wart with pack and pack_into too.

The current interface makes sense when if v1, v2 are a small number of
items from a data record, but it becomes a bit silly when v1, v2, ... are
the elements of an array of 10 000 integers, for example.

The option to take a list-like argument like you suggest is a good idea,
but maybe this should have its own function or is just outside the scope of
the built-in struct module.

Multiprocessing sort of added support for this via multiprocessing.Array --
see
https://stackoverflow.com/questions/9754034/can-i-create-a-shared-multiarray-or-lists-of-lists-object-in-python-for-multipro.
I haven't looked at what multiprocessing.Array does under the hood.

Summary of the StackOverflow answer for those who don't feel like clicking:

   mp_arr = mp.Array(c.c_double, size)
   # then in each new process create a new numpy array using:
   arr = np.frombuffer(mp_arr.get_obj())

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

[Python-Dev] Re: Thanks for your work in Python 3.10

[Simon Cross]

Thank you for managing the release, Pablo!

And for the awesome astrophysics snippets. :D
___
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/Y6RVLW6W7WLJNVQE6GXZHNUAUUKWP5LL/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: A better way to freeze modules

[Simon Cross]

Hi Gregory,

I think adding a meta path importer that reads from a standard
optimized format could be a great addition.

As you mentioned in your email, this is a big detour from the current
start-up performance work, so I think practically the people working
on performance are unlikely to take a detour from their detour right
now.

If you would like to see your suggested feature in Python, I *think*
the following might be a reasonable approach:

* Email python-dev about your idea (done already! :)

* Ask if there are any Python core developers who would be willing to
look at the early stages of the code and/or PEP that you might produce
in the next couple of steps. Perhaps also ask on one of the packaging
mailing lists. If you get others involved as reviewers or contributors
from the start, convincing them later that it is a good idea will be
much easier. :)

* Write the meta path importer in a separate package (it sounds like
you've already done a lot of the work and gained a lot of
understanding of the issues while writing PyOxidizer!)

* Write a PEP.

It seems to me that PEPs that come with an implementation and the
support of a few existing core developers have a much less painful PEP
review process.

Thank you for writing PyOxidizer and offering some of your time to
help make Python itself better.

Yours sincerely,
Simon Cross

P.S. I am not a core developer, and I haven't even written any PEPs. :)
___
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/LMHQ2S2YDJHQNQG3U65GIUPU6IB5QDXY/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: My apologies to the list

[Simon Cross]

On Wed, Aug 25, 2021 at 9:28 PM Brett Cannon  wrote:
> I just wanted to apologize for any angst or noise my replies to Marco caused 
> folks.

Caring enough to write this email shows that you are an awesome human
(like many other humans). :D

Please don't feel too bad about getting some mud on yourself -- this
is just part of the territory of wading into messy situations in an
attempt to help.

Everyone else can also carry some of the responsibility for their own
angst / emotions. We can all choose how we respond to unpleasant
things if we pause and think to do so.

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

[Python-Dev] Re: [Steering-council] Re: A ban from Core Developer spaces.

[Simon Cross]

Hi Brett,

Thank you for the quick reply.

On Thu, Aug 26, 2021 at 8:58 PM Brett Cannon  wrote:
> Marco was given a previous 3 month suspension on discuss.python.org (as Marco 
> himself pointed out on the email thread in question). Speaking for myself, 
> Marco was given a chance previously to take some time to think about how he 
> approached communicating and it didn't seem to be enough time.

"A three month suspension was tried and didn't result in a better
outcome" seems a solid reason for issuing a different suspension this
time. Thank you for the background & explanation.

> I will also note that Marco publicly asked me to ban him for life in one of 
> his emails in the thread as well.

It seemed clear to me that Marco's statement was intended as a
criticism of the banning process, or perhaps a request to be martyred.
Either way, not really a good reason to impose or not impose a
particular ban.

Re python-dev's future:

> I am purposefully not replying to this as I don't want to spark a 
> conversation on this topic in this email thread.

Fair enough -- one topic per thread. However, as someone who engages
primarily through python-dev, I would like some sort of more open
debate on it's future on the list before anything drastic happens to
it.

/me heads off to sleep.

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

[Python-Dev] Re: A ban from Core Developer spaces.

[Simon Cross]

Hi Thomas,

Could I ask a bit about the thinking behind extending the ban to a
year? A year is a long time and to me feels similar to asking someone
to go away and never come back. It's much longer than is needed to go
away and think about things.

Re the future of python-dev: That sounds a bit ominous. Is the
Steering Council considering removing python-dev? Eek.

Yours sincerely,
Simon Cross
___
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/XRCPPKUSA3ZVC3J2W2QGKLHO6NQHRTND/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Dropping out of this list

[Simon Cross]

On Thu, Aug 19, 2021 at 4:15 AM Tim Peters  wrote:
> If you want more active moderation, volunteer for the job. I'd happily
> give it up, and acknowledge that my laissez-faire moderation approach
> is out of style.

I, for one, welcome your laissez-faire moderation approach. :D
___
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/CVEMNLRVWFGHNTADZNHZW6SKXURMLLL4/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: [RELEASE] Python 3.10.0b3 is available

[Simon Cross]

On Thu, Jun 17, 2021 at 11:36 PM Pablo Galindo Salgado
 wrote:
> #And now for something completely different
>
> There are no green stars. Why?

Thank you! This addition was great. :D
___
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/PQHHFC2XHTXM3F5RBDELC5W5JN5XPLNA/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: New pythoncapi_compat project adding Python 3.10 support to your C extensions without losing Python 2.7-3.9 support

[Simon Cross]

On Thu, Jun 3, 2021 at 4:16 AM Victor Stinner  wrote:
> I would say that HPy is not complete nor mature yet. IMO it's already
> worth it to start playing with it, try to convert your small C
> extensions, and send back your early feedback to HPy developers!

This is my view of the state of HPy too. It's a really good time to
try things out and give feedback. Once we start doing more official
releases, changing fundamental things about the HPy API will become
harder (or at least more work).
___
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/P6AQ5TMFGOQUDCTSWBBQJK3SJRCUIKOJ/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Revive PEP 396 -- Module Version Numbers ?

[Simon Cross]

Replying to myself to update my own thoughts:

I think __version__ and packaging tools answer separate questions.

__version__ answers the question of "this module I imported, what
version is it".

The packaging tools answer the question "what dependency does this
distribution satisfy".

This mismatch is why importlib.metadata.version("bs4") doesn't return
a useful answer. A single distribution might even install multiple
top-level modules with different versions.

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

[Python-Dev] Re: Revive PEP 396 -- Module Version Numbers ?

[Simon Cross]

Replying to the original email because my comment is more a thought
after reading the whole thread rather than a response to any
particular message.

What I love about __version__ is that it is simple. It doesn't come
with the complexity of solutions like `importlib.metadata.version`.
The maintainers of the project arranged for it to be set**. It doesn't
depend on how the module was packaged or distributed.

I also don't think it's really a language update or requires any
changes in the stdlib -- it's just a standard for the community to
follow where none currently exists.

It's also probably far from the end of the world*** if it doesn't
happen, but I still like the idea.

** It might have been updated somewhat automatically -- my point here
is that distutils, setuptools, packaging, pip, wheels, PyPI were all
not involved.

*** Although that is likely true of most PEPs, even much more
complicated ones. :)

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

[Python-Dev] Re: New public C API functions must not steal references or return borrowed references

[Simon Cross]

I (with a lot of help and input from other people) wrote up some of
the thinking behind these kinds of API issues for the HPy project --
https://github.com/hpyproject/hpy/wiki/c-api-next-level-changes#what-needs-to-change-and-why

It's written from an HPy point of view and if you've already thought
about these things a lot none of it may be new to you and you may have
your own opinions, but hopefully it's a good introduction to the
issues if one is new to them.
___
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/6VHFDRL4T2IVS5ALDKD4M2ZY7HFDZGQN/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: New public C API functions must not steal references or return borrowed references

[Simon Cross]

On Thu, Mar 25, 2021 at 9:01 PM Mark Shannon  wrote:
> Maybe the problem is the term "stealing".
> The caller is transferring the reference to the callee.
> In some circumstances it can make a lot of sense to do so, since the
> caller has probably finished with the reference and the callee needs a
> new one.

The problem with both borrowed and stolen references is that they
implicitly expose the lifetime of the reference as part of the API.

I agree that borrowed references are worse in some sense (there is no
way to indicate that one is done with a borrowed reference at all).

Stolen references are not great though. As you mention, in theory one
can treat the stolen reference as having been DECREF'ed and never use
it again, but in practice that's hard to do. When reviewing or writing
code, one has to remember precisely which API functions steal a
reference. One can no longer reason about whether the reference
counting is correct by looking for appropriate DECREF's. It's very
hard for tools to help pick up mistakes because the reference was
freed -- just not necessarily at the right time.

Of course it is hard to avoid these kinds of problems as long as
pointers to PyObjects and reference counting are part of the API, but
let's not make it more difficult to write correct code unless there is
a really big advantage to be had by doing so.

I also don't see the rules that Victor is proposing as absolutes. More
of a "let's have a big conversation before doing this" kind of rule.

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

[Python-Dev] Re: Speeding up CPython

[Simon Cross]

On Mon, Jan 25, 2021 at 1:30 AM Terry Reedy  wrote:
> The Python Software Foundation currently has a shortfall of funds rather
> than a surplus.

I believe Mark's proposal suggested raising money specifically for the
project, not spending general PSF funds.
___
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/CULJ7Z5M5CDO5DODF3D4EVKETT3VQXK7/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Heap types (PyType_FromSpec) must fully implement the GC protocol

[Simon Cross]

Hi Victor,

Thank you for looking into these issues. They are very important to HPy too!

HPy currently only supports head types for similar reasons to why they
are important to sub-interpreters -- their lifecycle can be managed by
the Python interpreter and they are not tied to the memory and life
cycle of the dynamic library containing the C extension. E.g. with
heap types the interpreter can control when a type is created and
destroyed and when it can be accessed.

We've run into some minor issues with the limitations in PyType_Slot
(https://docs.python.org/3/c-api/type.html#c.PyType_Slot.PyType_Slot.slot)
but we are working around them for the moment.

It would be useful to have some sense of where PyType_FromSpec is
headed -- e.g. is it a goal to have it support all of the features of
static types in the future -- so that we can perhaps help suggest /
implement small changes that head in the right direction and also
ensure that HPy is aligned with the immediate future of the C API.

Yours sincerely,
Simon Cross
___
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/GXZI7T2KGAU3BNKNW6E4CKDTECLZAUGX/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: macOS issues with 3.8.7rc1

[Simon Cross]

On Wed, Dec 9, 2020 at 2:17 PM Ronald Oussoren via Python-Dev
 wrote:
> We know. Backporting the relevant changes to 3.8 is taking more time than I 
> had hoped. It doesn’t help that I’ve
> been busy at work and don’t have as much energy during the weekend as I’d 
> like.

Thank you for all your hard work on this! I've been in similar
positions as a maintainer in the past (long work days and too tired to
get to open source fixes in the evenings or on weekends).

Please look after yourself -- it's better for everyone if the patch is
delayed some months than to have you get burned out (or even just not
enjoy contributing).

Many open source contribution journeys begin with someone scratching
an itch, so it's okay if there are itches for people to scratch. :D
___
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/27MUX65R52HZNGSIPNBRCC2ITFJUFMKM/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: [RELEASE] Python 3.9.1rc1 is now ready for testing

[Simon Cross]

Thank you release team and all the bug fix contributors!
___
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/QSNRO6R2OOJC6EMIFPT6MZ5HTMCSTKCM/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Review patch fixing packed bitfields in ctypes struct/union

[Simon Cross]

The PR already has a fair amount of good review and discussion. Me
doing a superficial review is not going to help get it merged.
___
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/B72DDTOXEZQ57GC2C2PWDOJ436IOLWR3/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Review patch fixing packed bitfields in ctypes struct/union

[Simon Cross]

Hello!

Thank you for this patch! I can't help land it, but it looks sane to me.

I fear you have discovered a fundamental truth about ctypes though --
it tries to mimic what C compilers do and this inevitably leads to
many discrepancies. E.g. if a C structure you're trying to use is
wrapped in an #ifdef, one has to then try to mimic that ifdef in
Python, which may be impossible or very fragile.

If you're encountering such issues, you might save yourself future
pain and bugs by switching to an alternative approach (cython, CFFI,
struct module -- it depends on what problem you're trying to solve).

Will hold thumbs that you find someone to review and merge the patch!

Yours sincerely,
Simon Cross
___
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/HGU2WTLRHTCIR6D5VLSV7A5I3MW3PI5L/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Please do not remove random bits of information from the tutorial

[Simon Cross]

+1e6 + 5j # :)
___
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/YRUHXXBY2AWT7QSXJ5373FYLQPASQVVH/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Please do not remove random bits of information from the tutorial

[Simon Cross]

On Mon, Nov 9, 2020 at 6:38 PM Chris Angelico  wrote:
> The name "tutorial" definitely screams "thing you should go through
> first". It shouldn't have to teach you everything. Keep the tutorial
> simple.

That's quite subjective. Personally I prefer a more complete tutorial
which explains many details so that I don't immediately run into
fundamentals I don't understand when I start using what I've learned.
K was very popular, so I don't think I'm alone in this.
___
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/4LWCOZ7IGFRO67BDUOG2G4FAJW6NTEWH/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Please do not remove random bits of information from the tutorial

[Simon Cross]

I really enjoyed learning from this "user manual with a strong
narrative component" so I would personally like to see it stay even if
a new tutorial is created for a different kind of audience.
___
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/GENCYD7WLJTF34LGDC4TN4RXDPN7O2M3/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Speeding up CPython

[Simon Cross]

On Wed, Oct 21, 2020 at 4:28 AM Terry Reedy  wrote:
> I don't think the two projects are mutually exclusive.

100% agreed. I would even go as far as to say that HPy and other
proposals to improve Python are mutually beneficial. HPy aims to
remove dependencies between C extensions and Python internals, so that
Python internals can evolve more easily. Someone else still needs to
do the evolving.
___
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/LRNDTBSPIM26ITQPQJER3UPQPLKSO5SS/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Speeding up CPython

[Simon Cross]

Since HPy was mentioned, hello from the HPy team!

If anyone is thinking about Python performance or new Python VMs, we'd
love them to take a look at HPy and come and talk to us. HPy is meant
to provide a new C API layer that any Python VM could implement in
order to efficiently support Python extensions written on top of HPy.
Amazingly, such extensions would also be backwards compatible (i.e.
they would also run on CPython as it exists today).

If you'd like to talk to us (and we would like to talk to you) you can
find us at:

* Mailing list: hpy-...@python.org
* IRC: hpy-...@python.org

If you would like to contribute as a developer (or any other way),
we're here to help (and at the moment I am prioritising landing other
people's contributions pretty much full-time).

If someone has money to donate, they can donate to the project at
https://opencollective.com/hpy/contribute. We have quite a few
contributors who could contribute more time than they do in exchange
for money.

HPy is currently in quite an early stage of development (we can
already run some simple Python C extensions without any performance
penalties on CPython). The upside is that right now we can consider
almost any suggestion for improving HPy because none of the design is
set in stone. In a few months it might be helpful to have people try
porting some (many) C extensions to HPy to see how that goes.

Yours happily,
Simon Cross (random person working on HPy)
___
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/ARSII7KMZZ5W6UMKR7LIQDIWFSWWYQLZ/
Code of Conduct: http://python.org/psf/codeofconduct/

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

[Simon Cross]

Yay! Thanks Larry!

And they were two of the releases which really helped Python 3 take off. :D
___
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/U3M5RTYDUTQGHTCZZ3UZPLPNB3DZAEWN/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: PR checks hang because travis does not report back to github

[Simon Cross]

On Sun, Oct 4, 2020 at 8:34 PM Mariatta  wrote:
> Perhaps we can relax the rule to allow administrators to merge the stuck PRs. 
> At least
> temporarily until Travis/GitHub fixes it. Does this sound okay?

+1 on relaxing the rule permanently. We should not give robots more
rights than humans.

People before Processes is the very first principle in the Agile
Manifesto (and with good reason).
___
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/WNGCNNETLTYD5TT2DCZZSWDHQ5PTB22C/
Code of Conduct: http://python.org/psf/codeofconduct/

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

[Simon Cross]

I don't know if they suit your purposes, but both sqlite3 and a small array
implementation are already available:

https://github.com/micropython/micropython-lib/tree/master/sqlite3
https://github.com/v923z/micropython-ulab
___
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/ITYDEI7RKIDYKULJWK7H5HW32GZZQS3D/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: PEP 622 railroaded through?

[Simon Cross]

On Fri, Jul 3, 2020 at 4:42 PM Rob Cliffe via Python-Dev <
python-dev@python.org> wrote:

> And since the PEP has Guido's authority behind it, I think
> it is likely that it will eventually be accepted pretty much as it was
> originally written.
>

This seems a bit unfair to Guido. He seems to put a lot of effort into
taking onboard feedback and I would prefer it if the community encouraged
long term contributors to keep contributing, rather than suggesting that
this was somehow problematic (of course new contributors are good too, as
are new-and-old contributors working together).

Full disclosure: I'm not a huge fan of this PEP myself -- it seems to add a
lot of new syntax to support a coding idiom that I consider an anti-pattern
-- but others seem to have raised similar points to mine, so I think my
point of view has already been fairly well represented in the discussion.
___
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/YCLL5H7NYKUEEBTQHPQSRQANV5JKFAQ4/
Code of Conduct: http://python.org/psf/codeofconduct/

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

[Simon Cross]

Maybe we can have a two-for-one special? You can add a new function to the
API if you deprecate two.
___
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/XE6ZO5Z4LKTJBVE3P77AMLR5SDQ2RQXA/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Deprecating the "u" string literal prefix

[Simon Cross]

On Tue, Dec 3, 2019 at 7:42 PM Guido van Rossum  wrote:

> I think it’s too soon to worry about this. I don’t see a reason to harass
> people who maintain code based that were just recently migrated.
>

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

[Python-Dev] Re: Steering Council Update for July 2019

[Simon Cross]

Is there a way for people to give input to the challenges facing Python
discussion? I'm picturing something like people writing short statements of
perceived challenges and submitting them so that the SC has more ideas on
its radar.
___
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/SJJ5JY5LPL3OQF2GSZVUJ5PZSVW5USO3/

Re: [Python-Dev] Expected stability of PyCode_New() and types.CodeType() signatures

[Simon Cross]

On Sat, Jun 1, 2019 at 12:29 AM Terry Reedy  wrote:

> We try not to.  There is already too much work.
> ...
> That was removed from the PR before it was merged.
> ...
> That was merged.
> ...
> Another chunk was added to What's New.
>

Woot to all of these! :)
___
Python-Dev mailing list
Python-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] Expected stability of PyCode_New() and types.CodeType() signatures

[Simon Cross]

As the maintainer of Genshi, one the libraries affected by the CodeType and
similar changes, I thought I could add a users perspective to the
discussion:

Genshi is a templating engine that parses Python code from inside its
templates. It supports Python 2.6+, 3.2+, pypy2 and pypy3. It parses Python
using compile(...) and then walks the AST to, for example, translate
variable lookups into template context lookups.

Pretty much every major release of Python has broken Genshi's Python
parsing in some way. While on the one hand this is a bit annoying, I also
don't want Python to stop evolving where it makes sense.

My requests to core developers are largely pragmatic:

* Try not to change things unless there's a good reason to (i.e. it makes
Python better).
* Don't try declare that these things shouldn't be used (there is not much
I can do about that now).
* Do warn people that these things evolve with the language.
* If changes do happen, try make them visible and give a clear description
of what has changed.

Also many thanks to the core developers who've submitted patches to update
Genshi in the past -- that was awesome of you.

The new CodeType.replace will remove some potential sources of breakages in
the future, so thank you very much for adding that.

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

Re: [Python-Dev] PEP 594: Removing dead batteries from the standard library

[Simon Cross]

Woot. +100 on this PEP.

> If the stdlib didn't have NNTP support, obviously nobody would suggest
> adding it nowadays.

Perhaps this is a good reason to keep nntplib in the deprecation list?
Another question is "are there any places using nntplib where `pip install
nntplib`" is not an reasonable option? There's quite a lot of time before
3.10 to move nntplib into an outside package.
___
Python-Dev mailing list
Python-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] Adding shlex.join?

[Simon Cross]

Software that "Just Works" and hasn't needed maintenance in years is the
best software. :D
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] VxWorks and cpython?

[Simon Cross]

It feels like it would be a good idea for Brian or someone else from
Wind River to work towards becoming a core developer? If Brian, et al
are interested, is there a core developer who would be willing to
mentor them?
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Arbitrary non-identifier string keys when using **kwargs

[Simon Cross]

I would consider it a feature. My reasoning is that the restriction on
what can be used as an identifier is a syntax restriction, not a
general restriction on what attributes or names can be.
___
Python-Dev mailing list
Python-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] dear core-devs

[Simon Cross]

Are there any core devs that Michael or Erik could collaborate with?
Rather than rely on adhoc patch review from random core developers.

Michael and Eric: Question -- are you interested in becoming core
developers at least for the purposes of maintaining these platforms in
future?
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] We cannot fix all issues: let's close XML security issues (not fix them)

[Simon Cross]

On Thu, Sep 6, 2018 at 5:06 PM Ryan Gonzalez  wrote:
> Thought: what if there's a label on the bug tracker meaning roughly "we're 
> probably not going to fix this anytime soon, but we won't mind someone 
> stepping up"?

Maybe "wouldlikehelpfixing"? :D
___
Python-Dev mailing list
Python-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] Guido's Python 1.0.0 Announcement from 27 Jan 1994

[Simon Cross]

Python Party Proposal!
___
Python-Dev mailing list
Python-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] Guido's Python 1.0.0 Announcement from 27 Jan 1994

[Simon Cross]

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

Re: [Python-Dev] [python-committers] Enabling depreciation warnings feature code cutoff

[Simon Cross]

On Wed, Nov 8, 2017 at 10:33 PM, Nick Coghlan  wrote:
> For interactive use, the principle ends up being "Code you write gives
> deprecation warnings, code you import doesn't" (which is the main
> aspect I care about, since it's the one that semi-regularly trips me
> up when I forget that DeprecationWarning is off by default).

I with Antoine here. The idea that "code in __main__" is the set of code someone
wrote really seems a lot like guessing (and not even very good guessing).

If everyone follows the "keep __main__ small" then scripts won't automatically
display deprecation warnings by default and so the original problem of "warnings
are easy to miss" remains.

Counter proposal -- why don't testing frameworks turn on warnings by default?
E.g. like pytest-warnings? That way people running tests will see warnings and
others won't unless they ask to see them.
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Proposal: go back to enabling DeprecationWarning by default

[Simon Cross]

I'm -1 on turning this on by default.

As a Python developer, I want to be aware of when deprecations are
introduced, but I don't want the users of my library or application to
care or know if I don't address those deprecation warnings for a few
months or a year. The right solution for me here seems to enable the
warnings in CI pipelines / tests.

As an end user, if I see deprecation warnings there's nothing I can
really do to make them go away straight away except run Python with
warnings turned off which seems to defeat the point of turning them on
by default. The right solution here seems to be for authors to test
their software before releasing.

I'm -2 on a complicated rule for when warnings are on because I'm
going to forget the rule a week from now and probably no one I work
with on a day to day basis will even know what the rule was to start
with.

Maybe there are ways around these things, but I'm not really seeing
what's wrong with the current situation that can't be fixed with
slightly better CI setups (which are good for other reasons too).

Schiavo
Simon
___
Python-Dev mailing list
Python-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] Aaron Hall, Introduction and pull-request bump

[Simon Cross]

Hello! And welcome aboard this mailing list ship. :)
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] [RFC] Removing pure Python implementation of OrderedDict

[Simon Cross]

I thought the decision a few years ago was that all modules that have a C
library for performance reasons should also have a Python version? Did this
decision change at some point? (just curious).
___
Python-Dev mailing list
Python-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 550 v3 naming

[Simon Cross]

What about "CoroutineScope" or "CoroutineContext"?
___
Python-Dev mailing list
Python-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] Parsing f-strings from PEP 498 -- Literal String Interpolation

[Simon Cross]

On Fri, Nov 4, 2016 at 9:56 AM, Eric V. Smith  wrote:
> 2. The parser sees that it's an f-string, and breaks it into expression and
> text parts.

I'm with Fabio here. It would be really nice to have a grammar
specified and documented for this step, even if it's not implemented
that way. Otherwise it's going to be very hard for, e.g., syntax
highlighters to know what is intended to be allowed.
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Why does base64 return bytes?

[Simon Cross]

On Tue, Jun 14, 2016 at 8:42 PM, Terry Reedy  wrote:
> Thank you for finding that.  I reread it and still believe that bytes was
> the right choice.  Base64 is an generic edge encoding for binary data.  It
> fits in with the the standard paradigm as a edge encoding.

I'd like to me-too Terry's sentiment, but also expand on it a bit.

Base64 encoding is used to convert bytes into a limited set of symbols
for inclusion in a stream of data. Whether bytes or unicode characters
are appropriate depends on whether the stream being constructed is a
byte stream or a unicode character stream.

Many people do deal with byte streams in Python and we have large
sub-communities for who this use case is important (e.g. Twisted,
Asyncio, anyone using the socket module).

It is also no longer 1980 though, and there are many protocols layered
on top of unicode character streams rather than bytes.

Ideally I'd like us to support both options (like we've been
increasingly doing for reading from other external sources such as
file systems or environment variables).

If we only support one, I would prefer it to be bytes since (bytes ->
bytes -> unicode) seems like less overhead and slightly conceptually
clearer than (bytes -> unicode -> bytes), but I consider this a
personal preference rather than any sort of one-true-way.

Schiavo
Simon
___
Python-Dev mailing list
Python-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] Regular expression bytecode

[Simon Cross]

This might be tricky for alternative Python implementations which
might compile regular expressions into something rather different.
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] The pysandbox project is broken

[Simon Cross]

Thanks for writing this email. It's well written and it takes a lot of
character to stand up and say you went down the wrong road. While I'm
here - thanks also for all your work on core Python. As a Python user
I really appreciate it.

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

Re: [Python-Dev] Getting Tulip (PEP 3156) into the 3.4 stdlib, marked provisional, named asyncio

[Simon Cross]

On Mon, Sep 30, 2013 at 1:51 AM, Larry Hastings la...@hastings.org wrote:
 My guess is, a lot of people would be disappointed if Tulip missed 3.4.  I
 suspect the community would rather we slip the beta a little if it meant it
 the difference between Tulip and no Tulip.

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

Re: [Python-Dev] please back out changeset f903cf864191 before alpha-2

[Simon Cross]

On Mon, Aug 26, 2013 at 5:57 PM, Antoine Pitrou solip...@pitrou.net wrote:
 What do you mean, all events have to be ready?
 If you look at the unit tests, the events are generated on-the-fly,
 not at the end of the document.
 (exactly the same as iterparse(), except that iterparse() is blocking)

So you have to poll .events()? That also seems unhelpful from an event
driven programming perspective.

What I'm driving at is that I'd expect to have access to some sort of
deferred that fires when the next event is ready to be processed and I
don't see that here.
___
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] please back out changeset f903cf864191 before alpha-2

[Simon Cross]

On Mon, Aug 26, 2013 at 2:51 PM, Antoine Pitrou solip...@pitrou.net wrote:
 Because this API is mostly useful when the data is received (*) at a
 slow enough speed - which usually means from the network, not from a
 hard drive.

It looks like all the events have to be ready before one can start
iterating over .events() in the new API? That doesn't seem that useful
from an asynchronous programming perspective and .data_received() and
.eof_received() appear to be thin wrappers over .feed() and .close()?

Am I misunderstanding something?
___
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] __subclasses__() return order

[Simon Cross]

I've used __subclasses__ as an easy way to register components by
sub-classing a base component. I didn't rely on the ordering. I guess
the current order depends on the order in which modules are imported
and so is pretty fragile anyway?
___
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] Accepting PEP 434, Idle Enhancement Exception

[Simon Cross]

Having a standalone version of IDLE might be really useful to
alternative Python implementations.
___
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] Submitting PEP 422 (Simple class initialization hook) for pronouncement

[Simon Cross]

On Sun, Feb 10, 2013 at 2:32 PM, Nick Coghlan ncogh...@gmail.com wrote:
 For those that don't recall the original discussion, the proposal is
 to add a new __init_class__ hook, invoked after the class object is
 created, but before the class decorators are applied. This provides a
 simple approach to inherited post-creation modification of classes,
 without the need for a custom metaclass.

Couldn't one just write a metaclass that calls __init_class__ for you?

Schiavo
Simon
___
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] BDFL delegation for PEP 426 (PyPI metadata 1.3)

[Simon Cross]

On Sun, Feb 3, 2013 at 9:42 PM, Daniel Holth dho...@gmail.com wrote:
 Bento is the only available packaging tool to heap praise onto and it is
 impressive.

If Bento is cool, is there some way we can help it gain more traction
in the Python ecosystem? Not necessarily by incorporating it into
stdlib, but perhaps by officially sanctioning it in other ways
(documentation, PyPI, perhaps getting some helpful hooks / tweaks to
Python itself)?

I don't know the answer to these questions, but if there is a good
solution out there, it would be cool to throw our community weight
behind it.

Schiavo
Simon
___
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] BDFL delegation for PEP 426 (PyPI metadata 1.3)

[Simon Cross]

On Mon, Feb 4, 2013 at 12:16 AM, Vinay Sajip vinay_sa...@yahoo.co.uk wrote:
 Bento is interesting, but I wouldn't jump to heap praise onto it. Apart from 
 the
 somewhat idiosyncratic source style, David Cournapeau himself points to what 
 he
 regards as weaknesses in it[1].

For the record, all the reasons listed at [1] appear trivial.

[1] http://bento.readthedocs.org/en/latest/faq.html#why-shouldn-t-i-use-bento

Schiavo
Simon
___
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.7.4

[Simon Cross]

On Sat, Jan 19, 2013 at 9:30 PM, Benjamin Peterson benja...@python.org wrote:
 It's been almost a year since 2.7.3, so it's time for another 2.7
 bugfix release.

 2013-02-02 - 2.7.4 release branch created; rc released
 2013-02-16 - 2.7.4 released

The Cape Town Python User Group is having a Python Bug Day next
weekend (26th  27th January) [1]. If there any particular 2.7 bugs
that need looking at please shout, otherwise we'll just work from the
top of the list of 2.7 issues on the bug tracker.

[1] http://ctpug.org.za/wiki/Sprint20130126

Schiavo
Simon
___
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] odd tuple does not support assignment confusion...

[Simon Cross]

l[0] += [1]

is the same as

l[0] = l[0] + [1]

Does that make the reason for the error clearer? The problem is the
attempt to assign a value to l[0].

It is not the same as

e = l[0]
e += [1]

which is the equivalent to

e = l[0]
e = e + [1]

This never assigns a value to l[0].

Schiavo
Simon
___
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] odd tuple does not support assignment confusion...

[Simon Cross]

On Sat, Mar 3, 2012 at 1:38 AM, R. David Murray rdmur...@bitdance.com wrote:
 What is even more fun is that the append actually worked (try printing
 l).

Now that is just weird. :)
___
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 414

[Simon Cross]

On Mon, Feb 27, 2012 at 5:44 PM, Armin Ronacher
armin.ronac...@active-4.com wrote:
 Agile development and unittests.  An installation hook means that you
 need to install the package before running the tests.  Which is fine for
 CI but horrible during development.  python3 run-tests.py beats make
 venv; install library; run testsuite anytime in terms of development speed.

python3 setup.py test works already with 2to3 (it builds the code
and runs the tests under build/). It is however slow and it can be a
bit annoying to have to debug things by looking at the generated code
under build/lib.linux-i686-3.2/ (or similar).
___
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] Proposing an alternative to PEP 410

[Simon Cross]

On Sun, Feb 26, 2012 at 1:31 AM, Guido van Rossum gu...@python.org wrote:
 I still think that when you are actually interested in *using* times,
 the current float format is absolutely fine. Anybody who thinks they
 need to accurately know the absolute time that something happened with
 nanosecond accuracy is out of their mind; given relativity such times
 have an incredibly local significance anyway.

There are good scientific use cases for nanosecond time resolution
(e.g. radio astronomy) where one is actually measuring time down to
that level and taking into account propagation delays. I have first
hand experience of at least one radio telescope (MeerKAT) that is
using Python to process these sorts of timestamps (Maciej even gave a
talk on MeerKAT at PyCon 2011 :).

Often these sorts of applications just use an large integer to hold
the time. Higher-level constructs like datetime tend to be too bulky
and provide functionality that is not particularly relevant. There is
also a lot of pressure to have all the details coded by an in-house
expert (because you need complete control and understanding of them,
so you might as well do it yourself rather than continually patch,
say, Python, to match your instrument's view of how this should all
work).

Hardware capable of generating nanosecond accurate timestamps is,
however, becoming fairly easy to get hold of (a suitable crystalline
clock slaved to a decent GPS unit can get you a lot of the way) and
there are probably quite a few applications where it might become
relevant.

I'm not sure whether any of this is intended to be for or against any
side in the current discussion. :D

Schiavo
Simon
___
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] Proposing an alternative to PEP 410

[Simon Cross]

On Sun, Feb 26, 2012 at 6:12 PM, Larry Hastings la...@hastings.org wrote:
 It's probably neutral.  But I do have one question: can you foresee the
 scientific community moving to a finer resolution than nanoseconds in our
 lifetimes?

I think we're already there. Even just in radio astronomy new arrays
like ALMA which operate a terahertz frequencies are looking at
picosecond or possibly femtosecond timing accuracy (ALMA operates at
~1000 times higher frequency than MeerKAT so they need ~1000 times
more accurate timing).

E.g. 
http://www.guardian.co.uk/science/2012/jan/29/alma-radio-telescope-chile-astronomy

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

Re: [Python-Dev] Add a new locale codec?

[Simon Cross]

I think I'm -1 on a locale encoding because it refers to different
actual encodings depending on where and when it's run, which seems
surprising, and there's already a more explicit way to achieve the
same effect.

The documentation on .getpreferredencoding() says some scary things
about needing to call .setlocale() sometimes but doesn't really say
when or why. Could any of those cases make locale do weird things
because it doesn't call setlocale()?
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Add a new locale codec?

[Simon Cross]

On Wed, Feb 8, 2012 at 3:25 PM, Victor Stinner
victor.stin...@haypocalc.com wrote:
 Sorry, I don't understand what do you mean by weird things. The
 locale codec doesn't touch the locale.

Sorry for being unclear. My question was about the following lines
from http://docs.python.org/library/locale.html#locale.getpreferredencoding:

On some systems, it is necessary to invoke setlocale() to obtain
the user preferences, so this function is not thread-safe. If invoking
setlocale is not necessary or desired, do_setlocale should be set to
False.

So my question was about what happens on such systems where invoking
setlocale is necessary to obtain the user preferences?

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

Re: [Python-Dev] Add a new locale codec?

[Simon Cross]

On Wed, Feb 8, 2012 at 3:25 PM, Victor Stinner
victor.stin...@haypocalc.com wrote:
 The current locale is process-wide: if a thread changes the locale,
 all threads are affected. Some functions have to use the current
 locale encoding, and not the locale encoding read at startup. Examples
 with C functions: strerror(), strftime(), tzname, etc.

Could a core part of Python breaking because of a sequence like:

1) Encode unicode to bytes using locale codec.
2) Silly third-party library code changes the locale codec.
3) Attempt to decode bytes back to unicode using the locale codec
(which is now a different underlying codec).

?

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

Re: [Python-Dev] Add a new locale codec?

[Simon Cross]

On Thu, Feb 9, 2012 at 2:35 AM, Steven D'Aprano st...@pearwood.info wrote:
 Simon Cross wrote:

 I think I'm -1 on a locale encoding because it refers to different
 actual encodings depending on where and when it's run, which seems
 surprising


 Why is it surprising? Surely that's the whole point of a locale encoding: to
 use the locale encoding, whatever that happens to be at the time.

I think there's a general expectation that if you encode something
with one codec you will be able to decode it with the same codec.
That's not necessarily true for the locale encoding.
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Add a new locale codec?

[Simon Cross]

Is the idea to have:

  bfoo.decode(locale)

be roughly equivalent to

  encoding = locale.getpreferredencoding(False)
  bfoo.decode(encoding)

?
___
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 408 -- Standard library __preview__ package

[Simon Cross]

On Sat, Jan 28, 2012 at 9:49 AM, Matt Joiner anacro...@gmail.com wrote:
 FWIW I'm now -1 for this idea. Stronger integration with PyPI and
 packaging systems is much preferable. Python core public releases are
 no place for testing.

+1. I'd much rather just use the module from PyPI.

It would be good to have a practical guide on how to manage the
transition from third-party to core library module though. A PEP with
a list of modules earmarked for upcoming inclusion in the standard
library (and which Python version they're intended to be included in)
might focus community effort on using, testing and fixing modules
before they make it into core and fixing becomes a lot harder.

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

Re: [Python-Dev] Python 3.4 Release Manager

[Simon Cross]

On Wed, Nov 23, 2011 at 6:50 AM, Senthil Kumaran sent...@uthcode.com wrote:
 That's cool.  But just my thought, wouldn't it be better for someone
 who regularly commits, fixes bugs and feature requests be better for a
 RM role? Once a developer gets bored with those and wants more, could
 take up RM role. Is there anything wrong with this kind of thinking?

There is something to be said for letting those people continue to
regularly commit and fix bugs rather than saddling them with the RM
role. :)

Schiavo
Simon
___
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] RFC: Add a new builtin strarray type to Python?

[Simon Cross]

On Sat, Oct 1, 2011 at 7:17 PM, Victor Stinner
victor.stin...@haypocalc.com wrote:
 I'm writing this email to ask you if this type solves a real issue, or if we
 can just prove the super-fast str.join(list of str).

I'm -1 on hacking += to be fast again because having the two loops
below perform wildly differently is *very* surprising to me:

s = ''
for x in loops:
s += x

s = ''
for x in loops:
s = s + x

Schiavo
Simon
___
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] RFC: Add a new builtin strarray type to Python?

[Simon Cross]

On Sun, Oct 2, 2011 at 7:23 PM, Simon Cross
hodgestar+python...@gmail.com wrote:
 I'm -1 on hacking += to be fast again because having the two loops
 below perform wildly differently is *very* surprising to me:

 s = ''
 for x in loops:
    s += x

 s = ''
 for x in loops:
    s = s + x

Erk. Bad example. Second example should be:

s = ''
for x in loops:
   b = s
   s += x

(I misunderstood the details but I new the reference counting
hackiness would lead to surprises somewhere :).

Schiavo
Simon
___
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] Maintenance burden of str.swapcase

[Simon Cross]

On Tue, Sep 6, 2011 at 10:36 PM, Martin v. Löwis mar...@v.loewis.de wrote:
 Which applications? I'm not sure the number of applications using
 str.swapcase gets even as high as ten.

 I think this is what people underestimate. I can't name
 applications either - but that doesn't mean they don't exist.
 I'm deeply convinced that the majority of Python code (and
 I mean *large* majority) is unpublished.

 I expect thousands of uses world-wide.

http://www.google.com/codesearch#search/q=swapcase%20lang:%5Epython$type=cs

There are quite a few hits but more people appear to be
re-implementing it than using it (I haven't gone to the trouble of
mining the search results to get an accurate picture though).
___
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] Maintenance burden of str.swapcase

[Simon Cross]

On Wed, Sep 7, 2011 at 6:31 PM, Simon Cross
hodgestar+python...@gmail.com wrote:
 http://www.google.com/codesearch#search/q=swapcase%20lang:%5Epython$type=cs

 There are quite a few hits but more people appear to be
 re-implementing it than using it (I haven't gone to the trouble of
 mining the search results to get an accurate picture though).

Scratch that -- I should gloss over search results less. It looks like
the most common use case is to provide a consistent string-like API
somewhere else. So removing it is liking to cause headaches (e.g. test
failures) for the people who are wrapping it.
___
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 the stdlib (was Re: LZMA compression support in 3.3)

[Simon Cross]

On Sun, Aug 28, 2011 at 6:58 AM, Terry Reedy tjre...@udel.edu wrote:
 2) It is not trivial to use it correctly. I think it needs a SWIG-like
 companion script that can write at least first-pass ctypes code from the .h
 header files. Or maybe it could/should use header info at runtime (with the
 .h bundled with a module).

This is sort of already available:

-- http://starship.python.net/crew/theller/ctypes/old/codegen.html
-- http://svn.python.org/projects/ctypes/trunk/ctypeslib/

It just appears to have never made it into CPython. I've used it
successfully on a small project.

Schiavo
Simon
___
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] Please revert autofolding of tracker edit form

[Simon Cross]

On Thu, Mar 31, 2011 at 12:54 AM, Nick Coghlan ncogh...@gmail.com wrote:
 Interesting - it comes straight up with the folded screen for me, no
 flickering at all.

I didn't get any flicker either and my first impression of the change
was also positive -- I usually skip straight to the comments the first
time I visit an issue.

Schiavo
Simon
___
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] Integrate the faulthandler module into Python 3.3?

[Simon Cross]

On Fri, Mar 4, 2011 at 2:58 AM, Victor Stinner
victor.stin...@haypocalc.com wrote:
 Some months ago, I proposed a patch to display the Python backtrace on a
 segfault. The API was not stable, it was too for Python 3.2, and it was
 enabled by default. I wrote a module instead of a patch so it can be
 used on any version of Python, and it has a better API. And now I would
 like to include the module into Python directly to use it more easily.
 See http://bugs.python.org/issue11393 for the details. The module:

While I like this module I'm against it going into the standard
library so soon. Modules need time to mature, develop and gain wide
adoption outside the standard library where they are less constrained
by maintaining compatibility with old versions and can enjoy shorter
release cycles.

There may be reasons for including a shiny new module in the standard
library despite the drawbacks (the rest of the standard library might
wish to use the new feature, for example). If there are such reasons
it would be nice to see them stated and discussed here.

Schiavo
Simon
___
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] Integrate the faulthandler module into Python 3.3?

[Simon Cross]

On Fri, Mar 4, 2011 at 3:26 PM, Victor Stinner
victor.stin...@haypocalc.com wrote:
 faulthandler is also a little bit special, because it is very specific
 to CPython: it is based on CPython internal structures.

If faulthandler is a public part of the standard library, what should
other Python implementations do about implementing it?

Schiavo
Simon
___
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] devguide: Generate patches without code checkout (Was: devguide: Write a guide to committing a patch.)

[Simon Cross]

On Wed, Feb 2, 2011 at 10:33 AM, anatoly techtonik techto...@gmail.com wrote:
 How about patches sent by users who track and fix bugs directly in
 codebase of their Python installation?

While I don't personally endorse the above approach, if you're going
to develop inside your installed site-packages folder it seems like a
good idea to at least version control that code by running hg init
or similar in the site-packages folder. Then you can create diffs
against older versions using hg diff.

If one is going to do something crazy one might as well go the whole
hog I guess. :)

Schiavo
Simon
___
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] alternate fix for urllib2 bug #8797

[Simon Cross]

Hi Sam

On Wed, Feb 2, 2011 at 5:55 PM, Sam Bull osir...@gmail.com wrote:
 This is my first stab at contributing to this list. I'm writing to lobby for
 bug #8797's fix to be removed and for my fix to put in in its place.

For what it's worth, I was already about to include your patch as a
workaround for the bug in 2.6. See Bitten issue
http://bitten.edgewall.org/ticket/658.

I also consider Sam's patch to be a cleaner patch than the one that
ended up being applied in Python. See my comments in the Bitten
mailing list thread:
https://groups.google.com/forum/#!topic/bitten/niJENqEGuus.

Schiavo
Simon
___
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] Import and unicode: part two

[Simon Cross]

On Wed, Jan 19, 2011 at 5:01 PM, Simon Cross
hodgestar+python...@gmail.com wrote:
 On Wed, Jan 19, 2011 at 2:34 PM, Victor Stinner
 victor.stin...@haypocalc.com wrote:
  (a) Python 3 doesn't support non-ASCII module names

 -0: I'm vaguely against this being supported because I'd rather not
 have to deal with what happens when the guess regarding the filesystem
 encoding is wrong. On the other hand, a general encouragement to stick
 to ASCII module names is probably functionally equivalent without
 imposing a hard restriction.

I'm changing my vote on this to a +1 for two reasons:

* Initially I thought this wasn't supported by Python at all but I see
that currently it is supported but that support is broken (or at least
limited to UTF-8 filesystem encodings). Since support is there, might
as well make it better (especially if it tidies up the code base at
the same time).

* I still don't think it's a good idea to give modules non-ASCII names
but the consenting adults approach suggests we should let people
shoot themselves in the foot if they believe they have good reason to
do so.

Schiavo
Simon
___
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] Import and unicode: part two

[Simon Cross]

On Wed, Jan 19, 2011 at 2:34 PM, Victor Stinner
victor.stin...@haypocalc.com wrote:
  (a) Python 3 doesn't support non-ASCII module names

-0: I'm vaguely against this being supported because I'd rather not
have to deal with what happens when the guess regarding the filesystem
encoding is wrong. On the other hand, a general encouragement to stick
to ASCII module names is probably functionally equivalent without
imposing a hard restriction.

  (b) Python 3 doesn't support unencodable characters in the module path

+1: It'd be nice if Python could import modules regardless of what
folder names people happen to have on their module path.

Schiavo
Simon
___
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] Import and unicode: part two

[Simon Cross]

On Wed, Jan 19, 2011 at 10:32 PM, Terry Reedy tjre...@udel.edu wrote:
 I am a little shocked at the so-far tepid response to (a), so let me
 defend and explain my claim that it is a bug.

 In the simplest case (from 6.11. The import statement and  2.3. Identifiers
 and keywords)

 import_stmt ::= import module
 module      ::= indentifier
 identifier  ::= appropriate Unicode start and continue chars

 There is nothing, nothing, about any restriction on identifiers.

I have no problem with non-ASCII module identifiers being valid
syntax. It's a question of whether attempting to translate a non-ASCII
module name into a file name (so the file can be imported) is a good
idea and whether these sorts of files can be safely transferred among
diverse filesystems.

For similar reasons we tend to avoid capital letters in module names.

Schiavo
Simon
___
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] Continuing 2.x

[Simon Cross]

2010/10/28 Kristján Valur Jónsson krist...@ccpgames.com:
 But the patient is very much alive and kicking, no matter what the good
 doctor declares.

No no! 'E's pining!

Schiavo
Simon
___
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] question/comment about documentation of relative imports

[Simon Cross]

On Tue, Oct 5, 2010 at 4:56 PM, Darren Dale dsdal...@gmail.com wrote:
   from ...sys import path

   Note that while that last case is legal, it is certainly
 discouraged (insane was the word Guido used).

Only if by legal you mean happened to work. It stops happening to
work in Python 2.6.6. :)

Generally I'm +0 on relative imports as a whole.

Schiavo
Simon
___
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] Proposed tweaks to functools.wraps

[Simon Cross]

On Wed, Aug 11, 2010 at 4:39 AM, Benjamin Peterson benja...@python.org wrote:
 Namespace conflict with what? I would prefer wraps unless it's
 standardized as a behavior for all decorators.

Having the original function available as __wrapped__ would be really
cool, although I'm not quite sure what the behaviour should be in
corner cases like:

* The decorator returns the original function (I suppose a reference
to itself is okay?)
* The decorator returns the a function that is already decorating
something else.

Schiavo
Simon
___
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] Proposed tweaks to functools.wraps

[Simon Cross]

On Wed, Aug 11, 2010 at 3:00 PM, Steven D'Aprano st...@pearwood.info wrote:
 * The decorator returns the original function (I suppose a reference
 to itself is okay?)

 There's no reason why a function can't have an attribute that refers to
 the function itself. It works fine:

Yes. But it's more common for the original function to have be
modified in some way. e.g.:

def autodoc(f):
f.__doc__ += document_args(f)
return f

@autodoc
def f(x, y):
 Add two numbers
 return x + y

And then f.__wrapped__ is not particularly useful because the original
function no longer exists and odd things will happen. For example, in
the code above autodoc(f.__wrapped__).__doc__ will not equal
f.__doc__.

 * The decorator returns the a function that is already decorating
 something else.

 That shouldn't make any difference. Given:

 @wraps(f)
 def func(*args):
    do_something()
    return f(*args)

 then func.__wrapped__ gives f. If f itself wraps (say) g, and g wraps h,
 then you have:

I guess my description of the problem wasn't clear. I meant:

def _debug(*args, **kwargs)
print args, kwargs

def mock(f):
return _debug

@mock
def plus(a, b):
   return a + b

@mock
def prod(a, b):
return a * b

Schiavo
Simon
___
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] Proposed tweaks to functools.wraps

[Simon Cross]

On Wed, Aug 11, 2010 at 11:21 PM, Nick Coghlan ncogh...@gmail.com wrote:
 However, as I noted before, these kinds of scenario are the reason we
 decided that building this feature directly into the decorator
 machinery wasn't a good idea.

I agree. I was just replying to Steven's response to my post. :)

Schiavo
Simon
___
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 signal processing question

[Simon Cross]

On Tue, Jul 20, 2010 at 12:29 AM, Steve Holden st...@holdenweb.com wrote:
 Another potential developer walks away feeling unwanted?

Let just kill this thread here. SIGKILL can't be caught. :)

(I had sort of assumed that Marcos was being ironic).

Schiavo
Simon
___
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] Intended behavior of backlash in raw strings

[Simon Cross]

On Tue, Jul 13, 2010 at 12:26 AM, John Arbash Meinel
john.arbash.mei...@gmail.com wrote:
 rtesting \ backslash and quote
 'testing \\ backslash and quote'

 It happens that this is the behavior I want, but it seemed just as
 likely to be an error. I tested it with python2.5 and 2.6 and got the
 same results.

The behaviour does appear to be explicitly documented in the language reference:


When an 'r' or 'R' prefix is present, a character following a
backslash is included in the string without change, and all
backslashes are left in the string. For example, the string literal
r\n consists of two characters: a backslash and a lowercase 'n'.
String quotes can be escaped with a backslash, but the backslash
remains in the string; for example, r\ is a valid string literal
consisting of two characters: a backslash and a double quote; r\ is
not a valid string literal (even a raw string cannot end in an odd
number of backslashes).


Schiavo
Simon
___
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] Licensing

[Simon Cross]

On Tue, Jul 6, 2010 at 11:05 PM, Terry Reedy tjre...@udel.edu wrote:
 1. Python License

 If there is not already, could there be an explanatory note, something like
 (worded to be 'neutral':

As a sub-point, I'd like to see something short explaining how the
different licenses in the LICENSE file are meat to be combined. At the
moment the terms and conditions section just lists them without
explanation.

Schiavo
Simon
___
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] Licensing // PSF // Motion of non-confidence

[Simon Cross]

On Mon, Jul 5, 2010 at 11:05 PM, Nick Coghlan ncogh...@gmail.com wrote:
 As Brett noted, yes, the LICENSE file is complicated, but most people
 don't bother reading it themselves - they ask what FSF and OSI think
 of it, and get the answers BSD style and GPL compatible and are
 happy with that.

Presumably at least the BEOPEN.COM LICENSE AGREEMENT FOR PYTHON 2.0
can be removed from the LICENSE file because otherwise it appears that
answer to GPL compatible must be no?

Schiavo
Simon
___
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] Regarding socket timeouts in httplib

[Simon Cross]

On Thu, Jul 1, 2010 at 10:33 AM, Anders Sandvig
anders.sand...@gmail.com wrote:
 2) Modify HTTPConnection.connect() to set the timeout on the socket
 object after it has been  created (using the same timeout as given on
 the HTTPConnection constructor).

It looks like urllib2 in trunk and urllib.request in py3k are also
affected by this oddity. My vote is for option 2 -- i.e. consider it a
bug that the timeout wasn't consistently applied.

Schiavo
Simon
___
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