> thanks for any tips.
Set sqlite_setup_debug to True in setup.py
Regards,
Martin
___
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/archiv
> Which is correct. Yet when I run my progam using the newly built python
> executable and attempt to use sqlite3
> functionality across threads it still says:
>
> ProgrammingError: SQLite objects created in a thread can only be used in
> that same thread.The object was created in thread id -12171
> I removed two messages by error in the bug tracker :-(
Please discuss tracker issues on tracker-discuss or, better yet, file a
report on the meta tracker.
> The second message is msg98284, part of #7774. How can I restore it? Or can
> "admin" restore it please? :-)
Done.
> There is an open i
> Any thoughts?
My initial reaction to this report, and still my current opinion is:
This issue is not a problem.
It's a boundary case, so it's not clear whether Python should be able to
deal with it gracefully. I doubt it's a realistic case.
Regards,
Martin
> Speaking for myself, I have an app with a daemon mode which I expect
> will sometimes behave as described; it answers requests and thus has I/O
> bound threads waiting for requests and dispatching replies, and threads
> doing data handling, which make constant use of the zlib library.
This is th
> Testing with a modified server that reflects the above indicates the new
> GIL behaves just fine in terms of throughput.
> So a change to the GIL may not be required at all.
Thanks - I think you put it better than I did.
Regards,
Martin
___
Python-Dev
> As for the argument that an application with cpu intensive work being
> driven by the IO itself will work itself out... No it won't, it can
> get into beat patterns where it is handling requests quite rapidly up
> until one that causes a long computation to start comes in. At that
> point it'll
> So, just to be clear about the my bug report, it is directly related
> to the problem of overlapping I/O requests with CPU-bound processing.
> This kind of scenario comes up in the context of many
> applications--especially those based on cooperating processes,
> multiprocessing, and message pass
Cameron Simpson wrote:
> On 15Mar2010 09:28, Martin v. L�wis wrote:
> | > As for the argument that an application with cpu intensive work being
> | > driven by the IO itself will work itself out... No it won't, it can
> | > get into beat patterns where it is handling requests quite rapidly up
> |
> If it's lurking behind a filesystem interface or in its daemon mode
> (remote archive store), multiple client processes can be using it at once,
> and it will be processing multiple tasks somewhat in parallel. Here one
> can get a compute bound thread answering one request, impacting quick
> resp
> You can't. This isn't an example where I am personally bitten by the GIL.
> I may be, but there's plenty of other stuff in terms of tuning or
> optimisation in my particular app before I get anywhere near the GIL.
>
> My point is not that it's biting me right now but that earlier you
> said the
Benjamin Peterson wrote:
> My plan is to tag 3.1.2 sometime on Thursday, so binaries can be built
> for the final release on Saturday. Agreeable?
Fine with me.
Martin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listi
> As mentioned I have access to a 16GB machine which is able to run the
> tests. The problem is that nobody seems interested in maintaining these
> tests.
So what do you propose to do?
I personally don't see that as a problem. Many rarely-used features get
infrequent testing - that's the nature o
Tim Lesher wrote:
> Now that Windows 9x is no longer supported (per PEP 11), would it be
> appropriate to replace the ANSI ("A") versions of Windows OS calls in
> posixmodule.c with their Unicode ("W") equivalents and remove the
> unicode_file_names() function that determines which version to call?
> Whether this is worth weeks of work or not will depend on a given
> student's knowledge about Python 3, and I'd suspect that the GSoC would
> be an opportunity for a number of applicant to actually learn the
> intricacies of Python 3.
> Developing Python 3-specific features could be used to incre
> Darn. I bet I broke it when I added the 'languishing' status. I even
> thought about that at the time but didn't follow up on it. I'll see
> if I can figure out where the script lives.
My guess is that the Debian upgrade killed it.
Regards,
Martin
__
> Or maybe you have a better idea? What's the equivalent situation on Windows
> and how would things work there?
On Windows, this problem is easy: create the directory with no
specification of an ACL, and it will (usually) inherit the ACL of the
parent directory. IOW, the same users will have wri
> refuse to create __pycache__ if I can't create it with the same ownership
> and permissions as the parent directory (and raise an ImportWarning).
I don't think an ImportWarning should be raised: AFAICT, we are not
raising one, either, when the pyc file cannot be created (and it may
well be t
Barry Warsaw wrote:
> On Mar 22, 2010, at 06:15 PM, Antoine Pitrou wrote:
>
>> What I am proposing is that the creation of __pycache__ /directories/ be put
>> outside of the core. It can be part of distutils, or of a separate module, or
>> delegated to third-party tools. It could even be as simple
Antoine Pitrou wrote:
> Martin v. Löwis v.loewis.de> writes:
>> If certain use cases
>> make it problematic (e.g. Apache creating directories which you then
>> cannot delete), there should be a way to turn it *off*. Perhaps the
>> existing machinery to turn of byte c
>> Why is it too late? Fix it, and get on.
>
> Sure, but it is annoying, and since it's the kind of things that noone
> (including sysadmins) ever thinks about in advance, it's bound to repeat
> itself
> quite often.
>
> It's especially annoying, of course, if you have to ask someone else to rem
> We now end with an alleged complete solution to a problem which doesn't
> seem to exist, or is at least vastly overblown (the idea that having pyc
> files along their source counterparts is a nuisance doesn't seem to be a
> common grief against Python).
>
> I would really recommend reexamining i
> Is there a need for python to use __pycache__ directories 100% of the
> time? For 2.x it seems like being flexible would be best, and if 3.x
> is going to be strict about it, it should be strict sooner than later
> rather than have a lot of 3rd party packages break at some point down
> the road
>> Having been active in bug triage and patch writing/reviewing since late
>> 2009, it was suggested in the python-dev IRC channel that I request commit
>> access to the repository. I'm primarily a Windows user and have worked with
>> many of the other active contributors to diagnose issues and tes
> Yes, I have signed a contributor agreement. I was thinking of just
> removing the license entirely, but if it's better to replace it with
> "Licensed to PSF under a Contributor Agreement", that's fine too. Let
> me know, and I'll take care of this today.
Technically, your *contribution* should h
> That's an ideal case, but it doesn't work, because more or less senior
> committers are already too busy. If they do not even have time to
> review issues, followup on patches - how can they monitor who reached
> the appropriate karma level?
The practice proves to be different. In the recent ad
anatoly techtonik wrote:
> So, there won't be any package management tool shipped with Python 2.7
> and users will have to download and install `setuptools` manually as
> before:
[...]
> So, do we need a PEP for that? How else can I know if consensus is
> reached? Anybody is willing to elaborate on
> now that the py3k warnings are fixed (see
> http://bugs.python.org/issue7092) we should run the tests on the trunk
> buildbots with the -3 flags, in order to check if new warnings are
> introduced and possibly to uncover other ones.
> It might be a good idea to add the -Wd flag too, both on trunk
> Is the requirement just the construction of full tracebacks in the
> event of an exception? Because Cython does that right now. In the
> event of an exception, the Python call frames are constructed as the C
> call stack is unwound. I thought Maciej was suggesting that having
> full Python frames
will...@ufpa.br wrote:
> First, thank you for all opnion. Each one was considered.
> I think the better question would be:
> I have to develop a project that involves compilers, and being a fan of
> Python, I thought about making a compiler for it (most basic idea involving
> Pythin and compilers).
Benjamin Peterson wrote:
> I propose that we freeze the trunk except for fixes for the buildbots.
> Thoughts?
Freezing sounds fine with me.
Martin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsu
> Can someone (Steve Turnbull?) confirm or refute my analysis?
Refute, see http://bugs.python.org/issue804885
> ISO-2022 input will
> be 7-bit, and the except will not trigger
This conclusion is false:
1. it is 7-bit
py> unichr(913).encode("iso-2022-jp")
'\x1b$B&!\x1b(B'
2. the except *will*
anatoly techtonik wrote:
> There is still a serious regression in zipfile module:
> http://bugs.python.org/issue6090
>
> And I would really like to see my issue with difflib tabs committed: =/
> http://bugs.python.org/issue7585
None of these are buildbot failures, so they can't go into 2.7b1,
by t
anatoly techtonik wrote:
> On Wed, Apr 7, 2010 at 2:10 PM, "Martin v. Löwis" wrote:
>>> There is still a serious regression in zipfile module:
>>> http://bugs.python.org/issue6090
>>>
>>> And I would really like to see my issue with difflib tabs c
Mark Dickinson wrote:
> On Wed, Apr 7, 2010 at 1:39 PM, Jeroen Ruigrok van der Werven
> wrote:
>> Before I file a bug report, is anyone else seeing this (in my case on
>> FreeBSD 8):
>>
>> Modules/_ctypes/libffi/src/x86/sysv.S:360: Error: junk at end of line, first
>> unrecognized character is `@
>> Instead of submitting a bug report, it would be better to submit a
>
> In *addition* to submitted a bug report, surely. :)
I'm not so sure. It's a ctypes/libffi bug, so most likely, nobody will
be able to fix it when reported. For platform-specific libffi bugs, the
patch most likely will come
> (also, as I understand it, the latest ctypes issues seem to have popped up
> after
> an update of the bundled libffi, so perhaps that update wasn't totally right,
> didn't choose the right libffi version, or missed some files?)
In the case of the SPARC issue: the bug is still exists in the libf
I have commented out all tests in test_gdb, yet
http://www.python.org/dev/buildbot/all/builders/sparc%20Ubuntu%20trunk/builds/47/steps/test/logs/stdio
still shows them being run. Can anybody explain that, please?
TIA,
Martin
___
Python-Dev mailing list
> FWIW I've attached a patch [1] to http://bugs.python.org/issue8330 which
> I believe may fix the issues seen in that log.
Thanks! I'll apply them after the beta release (don't want to mess with
it before).
Regards,
Martin
___
Python-Dev mailing list
P
> Any other advice would also be helpful.
I may be missing the point, but ISTM that the assumption of this
approach is that there are often collisions in the hash table. I think
that assumption is false; at least, I recommend to validate that
assumption before proceeding.
There are, of course, ca
It seems the Python (core) project needs some more mentors,
to really match the proposals that we got. I don't want to post a list
of proposals here, so if you are willing to potentially mentor a
project, please join the soc2010-mentors list ASAP and/or contact Arc Riley.
Doing so would neither be
> That said, it's easier to add components and keywords than it is to
> add a new selection box. I know how to do the former but not (yet)
> the latter.
It's not too difficult, either: edit schema.py to change the database
(roundup will automatically sync with the database), then edit
html/issue.
> Why is it unavoidable that the Mac build will languish behind others?
Because of lack of volunteers, and expertise (i.e. the experts lack time).
> Are we supporting MacOs or aren't we?
We aren't. Strictly speaking, "we" (python-dev) "support" nothing (in
the sense that "we" can promise a suppo
Tres Seaver wrote:
> Steve Holden wrote:
>> Why is it unavoidable that the Mac build will languish behind others?
>> Are we supporting MacOs or aren't we? If we are, why isn't the creation
>> of the build a part of the release process?
>
>> Clearly it's not a priority given that nobody has seen fi
> Wasn't that problem fixed weeks ago? The installer image has been
> available there since several days after the release. And the link
> seems fine now.
The inherent problem remains. There is no binary for 2.7b1, for example.
The last binaries produced in the 2.7 testing process were for 2.
>> In a wider sense of "to support", MacOS is certainly supported by
>> Python. There is everything in the source code that you need to make
>> Python run on a Mac. Just download the sources and compile them yourself.
>>
> And yet we don't regard the Windows release as complete until you have
> bui
> Mac users definitely *do* expect installers. Building Python requires, I
> believe, the XCode development tools to be installed. Even then,
> building a full version of Python - with *all* the C extensions that are
> part of a Python release - is not a trivial task.
The same is true for any othe
> I assumed that creation of installer binaries for a release depends on
> having the release manager or a lieutenant have access to the given
> platform (Windows, OS/X) and tools, For instance, the RM or lieutenant
> might only have access to such a platform part-time (e.g., only while at
> work,
> I personally think the Mac is pretty important, as one of the big three
> consumer operating systems...
[...]
> I don't know what to do about motivation but if there are barriers that
> we can lower, please let me know.
For example, you could volunteer to produce OSX binaries in a timely
manner
> I seem to recall there was some issue (aside from the current lack of a
> reliable OS X buildbot) that prevented us from regularly grabbing the
> head of the tree and using it to automatically build the Windows and Mac
> installers (to check that the installers could actually be created,
> preven
> Sure - but probably not your average Python-on-Mac user. Or at least a
> good proportion of them, particularly newbies who we are keen to keep
> the experience of obtaining Python simple. First download and then
> install 1gigabyte of developer tools (seriously) requiring registration,
> then com
> Speaking of which... I have a mac-mini that could be used for a
> buildbot. How much work is needed to kickstart a buildbot, taking
> into account that I'd prefer to have a buildbot with different
> configure-flags that the default unix build (that is, I want to test
> a framework build that is a
> Probably fine on your personal Mac. And the build scripts can probably
> mask those out on their own.
For a private Python installation, it doesn't actually hurt to have them
on disk. The binaries may be linked with strange libraries, but it
should work since the libraries themselves are also o
C. Titus Brown wrote:
> If Georg, Benjamin,
> Martin, or Ronald are interested, please just tell me (or Steve, or the PSF
> board, or ...) what you want and I'll work on getting it funded.
For me, my company provides all the infrastructure I need (tools,
bandwidth, hardware, etc). I agreed, in ret
Paul Rudin wrote:
> "Martin v. Löwis" writes:
>
>> The major difference in the "do it yourself" attitude is that Mac user
>> get a compiler for free, as part of the operating system release,
>> whereas for Windows, they have to pay for it (leaving al
Ned Deily wrote:
> That *is* something that the PSF could help with. I
> would be happy to help with that myself, although my time to do so will
> be very limited for the next few weeks.
The PSF still has a machine that was donated by Apple that once used to
be a build slave. Unfortunately, tha
> I'd be happy to help where I can, too. All my automated testing of
> UpLib (Windows, Ubuntu, Fedora, OS X) is done on Apple servers running
> OS X and VirtualBox and Hudson, so I've got some experience there.
Would you be interested in operating a build slave?
Regards,
Martin
_
> Making the Windows binary build process automatic and robust is challenging
> if you hate Windows (like I do). Martin also made the point that it's
> been broken forever, so people don't seem to care :). ISTR Martin just
> makes them manually.
That's true. In particular, people had been askin
> Michael Foord wrote:
>
>> Building the Mac installer requires volunteer time which I'm not sure
>> that more hardware will fix - compiling a full build of Python for Mac
>> OS X (with all the Python modules like Tkinter etc) requires expertise
>> which only a few people have.
>
> That's nuts.
> How about as a first step the release build process include a check for
> broken links before committing the web content for a new release?
You'd have to convince the release manager to add a step to the release
process.
Given that the release process has already too many steps, he is
probably
>>From what I recall, the PC build process is pretty much routine (I
> can't recall how much it's scripted, and how much it's manual, but
> well-documented and simple, steps). I don't know what extra is needed
> to build the final installer, but I'd be willing to have a go at
> testing the existing
> (ISTM the same might be true should people ever decide to once again build a
> Solaris installer. /opt/sfw is currently searched for Berkeley DB include
> files.)
And rightly so (likewise for Fink). Primarily, the script is there to
help people installing Python; packaging Python can be more di
> Right - but we were discussing this in the context of barrier to entry,
> particularly to new users. We don't impose this requirement for Windows
> users though - we provide binary installers.
>
> I *know* we're a volunteer organisation (etc), but it is good for us to
> be aware of our process w
> How would that work? Creation of the OSX installer is not integrated
> in the regular Makefiles but is a separate script.
Again by setting up another builder (and assigning it to either the same
or a different slave). Instead of the regular configure/make/make
test/make clean builder, this one
> I think you just need to supply to configure
>
> MACOSX_DEPLOYMENT_TARGET=10.4
>
> and have the appropriate SDK installed with Xcode.
Wouldn't that break 10.3 compatibility (seel below)?
>> Unfortunately, Apple manages to break compatibility and portability
>> with every release, which makes
Greg Ewing wrote:
> Michael Foord wrote:
>> Building Python requires, I believe, the XCode development tools to be
>> installed. Even then, building a full version of Python - with *all*
>> the C extensions that are part of a Python release - is not a trivial
>> task.
>
> What's non-trivial about
>>> What's non-trivial about it?
>> Building a DMG file, in a way that the output will actually work on most
>> other systems.
>
> As Ronald pointed out, the installer build script does all of the dirty
> work of building the install disk image (the .dmg file), including
> downloading and build
Ned Deily wrote:
> In article <4bc61278.7020...@v.loewis.de>,
> "Martin v. Lowis" wrote:
>> Ned Deily wrote:
>>> That *is* something that the PSF could help with. I
>>> would be happy to help with that myself, although my time to do so will
>>> be very limited for the next few weeks.
>> The PS
> In the first builds, I have noticed that the build master seems to
> execute the builds as a Unix system, so isn't building with the
> universalsdk option or as a framework, though the latter would
> probably need a bit of glue to make the framework available just
> locally to the buildbot proces
Senthil Kumaran wrote:
> http://bugs.python.org/issue2987
>
> This deals with a feature request of parsing an IPv6 URL according to
> standards. The patch is pretty complete and we have good test coverage
> too.
>
> Is it okay to include this in Python 2.7 b2 release? It would be a
> worthy add
> If it were working that could be of use. It would not be able to run OS
> X 10.6 but having a 10.5 system PPC system as a buildbot would certainly
> be useful; it should be fine for the default installer configuration
> builds. (Alas, I don't expect to be anywhere in the vicinity in the
> f
> Keeping the knowledge in the makefile or script in the source tree would
> let the rules change across branches without affecting the build master.
> Though if having more specific rules in the master was easier, I'd be
> fine with that too.
Intuitively, I find the set of batch files used for Wi
> what's the status of backporting PEP 3102 ?
It looks like it won't happen.
> It was supposed to go into
> 2.6 and it seems it won't be in 2.7 either.
Correct - and therefore, it won't be backported at all.
> There is an updated patch
> in the tracker [1] that applies cleanly on the latest t
Ronald Oussoren wrote:
> On 15 Apr, 2010, at 6:36, Martin v. Löwis wrote:
>
>> Greg Ewing wrote:
>>> Michael Foord wrote:
>>>> Building Python requires, I believe, the XCode development tools to be
>>>> installed. Even then, building a full version
> We can certainly start by just trying to automate the execution of
> build-installer, something I suspect can be completely controlled from
> the master side, and then uploading the resulting dmg file. I'd be
> happy to help coordinate any experiments offline if you're interested.
Sure!
> I do
> - many optparse programs use the version argument
> - many other programmers find this feature very convenient
> - dropping or deprecating this is a totally unnecessary change
> (I have not read a single real reason /why/ this should be done).
You actually brought up a good reason yourself:
I
Antoine Pitrou wrote:
> Victor Stinner haypocalc.com> writes:
>> It's a choice, I didn't want to patch Windows because I know that Windows
>> use
>> unicode internally. I consider that developers using Python3 should use
>> unicode on Windows, and byte or unicode+surrogates on other OS.
>
> I
> I'm working on surrogates in filenames on Linux (more generally on BSD and
> UNIX OS) to support undecodable filenames, see PEP 383. Amaury told me that I
> only fixed the non-Windows versions (I fixed subprocess about the current
> directory and _ctypes.dlopen()), but it doesn't work on Windo
> Amaury reopened my issue #8393 "subprocess: support undecodable current
> working directory on POSIX OS" because "It does not work on Windows" (bytes
> are rejected).
I see. I'd like to know whether that's an incompatible change. We
shouldn't make incompatible changes in that matter. However,
Phil Thompson wrote:
> When I build my C++ extension on Windows (specifically PyQt with MinGW)
> against Python v2.6.5 it fails to run under v2.6.4. The same problem exists
> when building against v3.1.2 and running under v3.1.1.
>
> The error message is...
>
> ImportError: DLL load failed: The s
Tim Golden wrote:
> I've got agreement in principle for one of our decommissioned
> servers to be repurposed as a Python buildbot. My idea would
> be to set it up as a Windows 2003 R2 server, at least partly
> because we don't seem to have any Windows server buildbots
> and it's a platform I'm espe
Antoine Pitrou wrote:
> Martin v. Löwis v.loewis.de> writes:
>> As for the operating system: I don't think it matters at all. Windows XP
>> Home is as fine a platform for this application as Windows 2008 R2
>> Enterprise. What would matter is processor architecture
>> As a starting point for further research, try the sxstrace utility of
>> your Vista installation.
>
> What Vista installation? XP I'm afraid...
Then you are out of look. Check the event log, and ask in Windows help
forums for better ways to analyse the problem.
Regards,
Martin
___
Nick Coghlan wrote:
> Tobias Herp wrote:
>> No deprecation or removal of the simple and convenient 'version'
>> argument is needed for this. Just omit it, and build your version
>> action yourself. But please notice that there are others who appreciate
>> this simple way to do it and don't need m
Sridhar Ratnakumar wrote:
> I am seeing random 403 errors when cloning the mercurial repositories of
> Python.
>
> $ hg clone http://code.python.org/hg/branches/release2.6-maint
> destination directory: release2.6-maint
> requesting all changes
> abort: HTTP Error 403: Forbidden
> $ hg clone http
> In general python.org seems flaky today. Sometimes I could not reach the site
> at all, now a ping to svn.python.org gives 30% packet loss.
Yes. See
http://www.python.org/munin/localdomain/localhost.localdomain-if_eth0.html
Somebody was consuming all bandwidth, although we couldn't quite figur
> If adding people created work for already-busy developers then I'd be
> against it*
I most certainly does create work, but that could be as little as
sending an email message to some administrator.
There is no other way: somebody will have to make a decision, and that
is "work".
Regards,
Marti
> Sounds good. Why is the barrier for this permission any higher than
> someone asking for it? Is there really a need to protect against
> contributors with malicious intent?
There is a little risk. People doing triage can make two common
mistakes, and both do happen in the Python tracker from t
> Maybe we can drop OSF/1 safely supporting Tru64 yet, but we don't have
> any buildbot running any of this systems...
Dropping support is fine with me, in the long term. If PEP 11 is truly
followed, we should deprecate support in one version, and drop it in the
next one. This would mean we add a
>> If possible, I think 'normal' should be the default in the hox or else
>> there should be some sort of auto replacement.
>
> Makes sense to me.
I have now changed to make 'normal' the default priority for new issues.
Shall I also set the priority on all past issues to normal which have
them cu
> Same here. Unfortunately I think that requires a code change as I can't
> see how to do it through the web API.
You have to write an auditor, which I just did.
Regards,
Martin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/ma
Eric Smith wrote:
> Martin v. Löwis wrote:
>>>> If possible, I think 'normal' should be the default in the hox or else
>>>> there should be some sort of auto replacement.
>>> Makes sense to me.
>>
>> I have now changed to make 'norma
R. David Murray wrote:
> On Mon, 26 Apr 2010 22:39:39 +0200,
> =?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?= wrote:
If possible, I think 'normal' should be the default in the hox or else
there should be some sort of auto replacement.
>>> Makes sense to me.
>> I have now changed to make 'no
Antoine Pitrou wrote:
> Antoine Pitrou pitrou.net> writes:
>> Speaking of which, what is the procedure to delete a spam message and remove
>> a
>> spamming user?
>
> Well, for some reason I hadn't seen the "remove button" message...
> As for deleting the user, I suppose an admin can do it.
For
> My perception is that making someone nosy on an issue is preferred to
> assigning it to them (allowing them to assign it to themselves if they
> think that is appropriate), unless the issue is of higher priority or
> someone actively working on the issue really needs the other person's
> input i
> Hmm, it feels exactly the other way around to me: working with the DVCS
> tools while reviewiing a patch allows me to be more productive (e.g.,
> using 'bzr shelve' or the equivalent hg subcommand).
Just try using Subversion for some time again, and you'll see that it is
not difficult at all. S
> The page doesn't document the Resolution or Status fields.
The resolutions are the same as the ones on SourceForge. You only have
resolutions on closed issues, and they explain why an issue was closed.
If any specific one is unclear in that context, please be more specific.
On the status, I hop
> The message was a copy of a previous message by someone else, with an
> additional
> HTML link in the middle. The target of that link was clearly the kind that
> would
> pay to increase its Google rank through whatever means (bogus diploma stuff,
> IIRC).
Ah, I missed that. I've marked it as
> When I open http://bugs.python.org/iss...@template=item
> priority is (still) set at no selection. Is this my local cache (which I
> do not know how to clear in FF) or is 'normal' filled in after submission?
It is filled in after submission.
Regards,
Martin
> You still want the auditor to make sure, but it is possible to set the
> default in the page template. Would you like a patch for that for
> consideration? If so, are there other elements it might be useful to
> have defaults for? (I would submit each as a separate patch.)
Feel free to submit
1001 - 1100 of 5277 matches
Mail list logo
